I have an additional feature request :-)
Grizzly has the ability to be configured in a blocking or non-blocking
mode. I would like to add an additional configuration which would be
applicable to applications which may have a small number of connections
as opposed to an application such as a web server that has a very large
number of connections.
This "additional configuration" I would like to see supported is one
that has a dedicated thread which accept new connections and dedicated
Selectors & WorkerThreads for each accepted connection. The accepted
connections would be configured as non-blocking connections.
Hence, there would a dedicated Selector which handles only OP_ACCEPT
events running in a thread. When a new connection is accepted, Grizzly
will create a dedicated Selector for that newly accepted connection and
place it in a WorkerThread where it will handle OP_READ (and possibly
OP_WRITE) events.
What this feature provides over the existing non-blocking configuration
is the ability to avoid the overhead of enabling and disabling interest
ops on the SelectionKey (system calls) and thread context switching
between the Selector where all OP_READ, OP_ACCEPT, etc interest ops are
registered and a WorkerThead. The advantage it has over the blocking
mode is that it can read as much data as is available and write as much
data as can be written. Hence, it can reduce the number of system calls
to read() & write().
The challenge with this configuration is that it does not scale well to
a very large number of connections like the default non-blocking
configuration does.
charlie ...
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>