Optimize internal connector causing high GC usage

[yanzhou2000]

The controller thread keeps looping over and over while trying to select ready channels and control connections, creating many Iterator objects and high GC usage.

One of the Iterator was removed but the second one is inside NIO Selector class. We need to have the controller thread sleep by default (as long as possible to prevent unnecessary CPU cycles, not too long to be able to collect idle connections) and wakeup/interrupt it when an event occurs such as:

1. NIO channel ready detected
2. Connection event detected (new connection/message/entity chunk to
   process)

See this wiki pages to details on this connector and the pending tasks:
http://wiki.restlet.​org/developers/172-r​estlet/g3/354-restle​t.html

See related discussion thread:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2970496

[jlouvel]

Updated title and description.

[yanzhou2000]

Thanks Jerome.

Can I add a use case or test case that has persistingConnections = false: a connection being closed from the server side would need to be closed as soon as possible. If there is otherwise a significant delay, a client that waits for the connection to be closed will see the delay.

[jlouvel]

That connection should indeed be closed immediately.

[jlouvel]

Most of the refactoring has been done, the controller doesn't infinitely and constantly loop anymore. This might have introduced some regressions/stability issues, but at least this issue should now be addressed.

[jlouvel]

We decided to replace the internal connector and move the still unstable NIO connector to an extension. See changes log:

  - Moved org.restlet.ext.net HTTP/HTTPS/FTP client connectors into the core
    org.restlet module (org.restlet.engine.net package) as the new internal
    client connectors.
  - Moved NIO-based internal connector to new org.restlet.ext.nio extension.
    Marked as "developer preview" state.
  - Added new internal HTTP/HTTPS server connectors based on the 
    com.sun.net.httpserver package available in JDK 6. Issue #381.
  - Moved org.restlet.ext.ssl into core org.restlet.engine.ssl package except
    classes related to the jSSLutils library now part of new org.restlet.ext.jsslutils
    extension and for CertificateAuthenticator class now in org.restlet.security.

This should solve the stability issues that occured with both HTTP and HTTPS server and client internal connectors bundled in org.restlet.jar.

For serious production load, we still recommend using the Jetty or Simple extensions though.

[jlouvel]

I'm setting the milestone to 2.2.0. Once this version is released and marked as the new "stable", 2.1 branch support will be deprecated.

@yanzhou2000 it would be great if you could try 2.2 RC1 released tomorrow to ensure that the new internal HTTPS connector solves this issue. It should definitely as it is based on the stable HTTP/HTTPS lightweight server part of JavaSE 6.