charlie hunt wrote:
> On the subject of a "write queue", no GlassFish ORB does not have one
> or use one. The WorkerThread which formulates an outbound message
> also writes the outbound message bytes. If the underlying channel
> cannot accept all the bytes to be written, that same WorkerThread will
> block using a temporary Selector until all bytes are written.
>
Yes, this probably is a good idea, but it also needs some flow control
(there was a recent message
about this from the MQ folks as well). Basically if we get too far
behind on writes, we need to
throttle the entire system (e.g. stop accepting new requests, which
ultimately blocks the clients
sending the requests) until the write queue length shrinks.
Also, there will be some processing required after the message write
completes.
Perhaps the only processing will be to call
InboundConnectionCache.responseSent()
after all of the bytes in the message have been sent (where exactly is that?
I've been having trouble finding that today). This should probably be
integrated
with Grizzly once we start using the new connection caches.
In fact, the write queue could be in Grizzly and completely transparent
to the Grizzly client.
Of course, this is also what the OS does underneath the Java VM, so I'm
not sure how much
queuing we should do here.
Note that there is currently NO call like responseSent in the ORB today,
so this is not
an issue.
Ken.