Hi all --
Jeanfrancois and I had exchanged a couple emails but he thought some of
my questions would be better addressed by the larger group of users on
this mailing list. So here goes for my first one:
I have all the data input processing working for my application, using
Controller and a ProtocolChain with SSLReadFilter and a custom Filter
for my application's binary message protocol. All is well with this --
I have added partial-read support in my Filter and am happily
dispatching messages in my WorkerThreadImpl's.
The question is about how to deal with write's. My app is essentially a
message queue, with mostly short binary messages (usu between 40-400
bytes). Right now, I'm writing messages back out using SSLOutputWriter
in a synchronous fashion inside Callable's that are running in the
WorkerThreadImpl's.
It looks like the Grizzly framework and NIO in general supports
asynchronous writes, but there do not seem to be many examples of that,
confirmed by JFA. It looks like most of the http response output is all
done synchronously, which makes sense due to inherent limitations in
following the javax.servlet specification.
It seems to me that tying up precious WorkerThread resources waiting for
synchronous write's to complete (where one is not bound by the
javax.servlet specification) is a bit wasteful and limiting in
scalability, especially if I have a client on the other end of a slow
connection, but I don't have any hard numbers to back me up on this.
In my application, all the events and messages can be handled
asynchronously, so I can build up a queue of outgoing Message objects
for each connection.
One possibility is to *always* have an object waiting for OP_WRITE
events managed by the Controller and SelectorThread and to have that
object basically "spin" waiting for messages or byte chunks to be
written. This seems inefficient at a gut level to me, especially if
waiting for messages/byte chunks involves any synchronization.
The other possibility would seem to be to *only* register an OP_WRITE
interest when there are messages in the outbound queue that need to be
written, triggered whenever a message is added to the outbound queue.
But in this case, there is an expense involved with waking up the
selector thread and registering/updating selection keys, etc.
Has anyone plowed into this area or am I breaking new ground here?
Thanks for any advice,
-=- D. J.
BTW, this is all for the back-end server scalability for
http://www.sun.com/sharedshell.