Grizzly 2.X Comet VS response.suspend

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Grizzly 2.X Comet VS response.suspend

wild
Hi Everyone,

I have some questions about grizzly 2.X and comet (or connection suspension more generally speaking).

I have already made some posts, asking why comet implementation did not use async write. Oleksiy Stashok answered that is made that way and that Grizzly team wanted to keep it like that 1.X because of backward compatility. He also told me it would be fixed for Grizzly 2.0.

I want to migrate to grizzly 2.0, but before that I'd like to ask some questions :

1. Does comet (in 2.0) uses asynchronous writing in order to prevent to block a thread ?
2. Do you think grizzly 2.0 is suitable for production ? Any feedback about grizzly 2.X used in production will be helpfull.

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.


1. If I call notifyCanWrite multiple times on the same outputstream, will all the handlers be queued and executed ? If the connection is closed (for any reason), did all the handlers will be flushed ?

2. Is there any way to be notified that a connection has been closed ?

Thanks.

Guillaume.
Reply | Threaded
Open this post in threaded view
|

Re: Grizzly 2.X Comet VS response.suspend

oleksiys
Administrator
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.

Reply | Threaded
Open this post in threaded view
|

Re: Grizzly 2.X Comet VS response.suspend

wild
Ok, I've looked at the code and it seems that comet interfaces has not changed. So I can use my existing  comet code that simply create an handler and call the write method on the response (right) ?

Now that writes are asynchronous, is it safe to call the flush method ?

What is happening if the write queue is full ? Should I handle an exception like you said for HttpServer ?

Is it possible that the momery growth a lot before grizzly find out that the client is disconnected ?

Thanks.

William.
Reply | Threaded
Open this post in threaded view
|

Re: Grizzly 2.X Comet VS response.suspend

oleksiys
Administrator
On 06/13/2011 07:58 PM, wild wrote:
Ok, I've looked at the code and it seems that comet interfaces has not
changed. So I can use my existing  comet code that simply create an handler
and call the write method on the response (right) ?
Yes.

Now that writes are asynchronous, is it safe to call the flush method ?
Yes, flush just flushes any data buffered in the response output stream.

What is happening if the write queue is full ? Should I handle an exception
like you said for HttpServer ?
Yes, PendingWriteQueueLimitExceededException is going to be thrown on queue overload.
Probably there is no much sense to handle it, because connection will be closed by that time. Though it's up to you for sure.

Is it possible that the momery growth a lot before grizzly find out that the
client is disconnected ?
It's not just about disconnected clients, but for example clients which read data slowly (may be on purpose).
Anyways, you can set the max async write queue size per Connection:

        final HttpServer server = new HttpServer();
        final NetworkListener listener =
                new NetworkListener("Grizzly",
                                    NetworkListener.DEFAULT_NETWORK_HOST,
                                    PORT);
        listener.setMaxPendingBytes(MAX_SIZE);
        server.addListener(listener);

Thanks.

WBR,
Alexey.