Hi Ilya,
considering your requirement, may be there is no reason to use Comet,
but regular asynchronous HTTP API?
With Grizzly 2.0, which will be released once work on docs is done,
you're able to use HTTP Request/Response NIO streams [1].
If you need just NIO output - it means you actually don't need to use
NIO OutputStream specific features, but just use it the same way as
java.io.OutputStream. Output data will be added to the async write
queue, so no blocking will happen.
It's possible to limit the max size of async write queue per client
[2], so when max is reached - PendingWriteQueueLimitExceededException
will be thrown.
Hope this will help.
WBR,
Alexey.
[1]
http://java.net/projects/grizzly/sources/svn/content/branches/2dot0/code/samples/http-server-samples/src/main/java/org/glassfish/grizzly/samples/httpserver/nonblockinghandler/NonBlockingHttpHandlerSample.java
[2]
final HttpServer server = new HttpServer();
final NetworkListener listener =
new NetworkListener("Grizzly",
NetworkListener.DEFAULT_NETWORK_HOST,
PORT);
final AsyncQueueWriter asyncQueueWriter =
listener.getTransport().getAsyncQueueIO().getWriter();
asyncQueueWriter
.setMaxPendingBytesPerConnection(<MAX_ASYNC_WRITE_QUEUE_SIZE>);
server.addListener(listener);
> I have a Java server application that runs in Tomcat and uses Tomcat
> Comet NIO. The application is used to send market data to multiple
> (thousands) clients.
> It uses Comet persistent connections to send data from server to
> clients (infinite GET response). It also processes "normal" GET
> requests of fixed response length.
>
>
> I have had a painful experience with Tomcat Comet/NIO. Besides the
> fact it has a large number of bugs, it has a design problem: writes
> block when client buffer reaches 32K. If I have a thread sending
> updates to multiple clients, it may block if one of the clients is
> “slow consumer” stopping data flow to multiple clients. There does
> not seem to be a workaround for it as Tomcat Comet API does not
> expose the size of this client queue.
>
>
> I want to potentially replace Tomcat Comet/NIO with Grizzly Comet. I
> have some questions:
> 1) Do you think Grizzly Comet is suitable API for my project. I
> noticed it centered around CometContext that is a "topic". I really
> want to have a fine control of each client connection and do not
> want to send messages to a "topic". Is it possible? Does creating a
> CometContext per client seem reasonable?
>
>
> 2) Is there a way to control/ access client send queues? Detecting
> "slow consumer" is critical for my app.
> Any help is appreciated.
> Thanks
>