Hi Guillaume,
> 1. Does comet (in 2.0) uses asynchronous writing in order to prevent to
> block a thread ?
Yes, in 2.0 Comet uses async write queue, so writes can't block your app.
> 2. Do you think grizzly 2.0 is suitable for production ? Any feedback about
> grizzly 2.X used in production will be helpfull.
We're integrating it into coming Glassfish release, so far we didn't see
any problems. Load tests are also passing without problems.
> Oleksiy also suggested to use HTTPServer directly, which seems fine since I
> already have a logic of groups implemented in my business logic code. I
> looked at NonBlockingHttpHandlerSample, it seems very simple to handle a non
> blocking read but I want to do non blocking write. I looked at the
> documentation and NIOOutputSink class should do the job but here are my
> questions.
HttpServer uses non-blocking write (async write queue) out-of-the-box,
so you shouldn't care about this at all.
The only possible issue - is that async write queue might be overloaded
if client is not able to read data fast enough. In this case
NIOOutputStream/Writer will throw PendingWriteQueueLimitExceededException.
In order to get finer control over async write queue and avoid its
overload, you may want to use notifyCanWrite method to make sure next
"write" method call won't throw PendingWriteQueueLimitExceededException.
> 1. If I call notifyCanWrite multiple times on the same outputstream, will
> all the handlers be queued and executed ?
We don't support handlers queue, next handler might be registered after
current one has been notified.
> If the connection is closed (for
> any reason), did all the handlers will be flushed ?
The onError method will be called on the current handler.
> 2. Is there any way to be notified that a connection has been closed ?
Handler's onError method should be called.
Thanks.
WBR,
Alexey.