Comments on: Buggy/Broken Tomcat 6 Comet NIO APIs

By: billburke

billburke — Fri, 21 Jan 2011 19:28:20 +0000

You could take a look at our HornetQ-REST interface. You'll have to tell me if it falls under your "long poll" implementation. It is beta, but going final when HornetQ 2.2 comes out next month.

By: Ilya Goberman

Ilya Goberman — Fri, 21 Jan 2011 17:09:38 +0000

I have had a mixed experience with Tomcat Comet/NIO. It is certainly very buggy.
The bug with “closing down sockets when it shouldn’t” (https://issues.apache.org/bugzilla/show_bug.cgi?id=50044) is actually fixed in Tomcat 7. But somehow they manage to introduce a new bugs very often. The latest version 7.0.6, for example, does not detect client disconnects: https://issues.apache.org/bugzilla/show_bug.cgi?id=50627
One other major problem is that 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. The only thing I can do is to allocate a thread per client – very ugly.

So my question is: are there any other “production ready” APIs in Java that handle Comet? I am not interested in long poll implementations or beta releases. I am starting to believe that there is nothing available in the Java world. Am I wrong?
Any input is appreciated. Thanks

By: billburke

billburke — Fri, 29 Oct 2010 13:33:05 +0000

Got a test to reproduce this? also, please move discussions to resteasy-dev list.

By: Shredder

Shredder — Fri, 29 Oct 2010 06:20:40 +0000

I’ve just been trying to use RestEasy + JBoss 5.1 + Tomcat6 APR wrapper. Running into problems when using RestEasy Async stuff via JBossWebDispatcherServlet, as well as JAX-WS separately. In other words, one’s using async, while all the others are using sync servlet handling. When an async response is sent at roughly the same time as a sync response, I keep getting ‘Stream closed’. I’m putting this down to the race conditions described here. Any ideas at a workaround?

By: What java comet-style framework is the most mature and robust? | DeveloperQuestion.com

Thu, 14 Oct 2010 16:31:23 +0000

[...] Comet, Jetty There seems to be significant issues with Tomcat6/Comet/NIO (example). Are the majority of people doing asynchronous http using something else? Jetty/continuations? [...]

By: billburke

billburke — Mon, 06 Apr 2009 19:12:15 +0000

@Nisse:

I guess the whole Tomcat community is screwed then. The Tomcat Comet guys don’t seem to know what they are doing or how to fix the problem. And Remy is an idiot Not my experience with him, but to each is own.

By: nisse

nisse — Mon, 06 Apr 2009 17:03:33 +0000

But Remy is one of the most incompetent programmers around.
the code he produces show very silly beginner mistakes, and a complete lack of understanding of any more advanced concepts, such as basic threadsafety.

he shoud be draged outside and shot in the head.

By: billburke

billburke — Wed, 01 Apr 2009 13:31:22 +0000

@Vlad

Try out JBossWeb. Remy has done a lot of work to stabilize this stuff. Would be interesting to know whether or not this is true

By: Vlad

Vlad — Wed, 01 Apr 2009 12:31:31 +0000

I have been trying to debug comet problems in Tomcat 6 (6.0.16).

It works OK most of the time but there are race conditions in both APR and NIO connectors which lead to Tomcat closing down sockets when it shouldn’t. If you set up clients and the Tomcat config to use HTTP keepalives you will see that occasionally a client request will fail because of a TCP RST. If you use the APR connector with HTTPS this will also show up as a SEGV in openssl function: ssl3_write_pending.

If you look at the Tomcat code in org.apache.coyote.http11.Http11AprProcessor#proces(), for example, you can see that the SocketState to return can depend on ‘comet’ boolean value. This value can be set from within process() or event() or in the action() callback. It is set in the action() callback from Response.finish() when closing a writer / stream.

The comet flag is not protected by locking but can be set from multiple threads if the response is sent on a separate thread. It is not thread safe. Code in the process() and event() functions appears to assume that the comet flag will not be set by another thread but that is possible. Also, because it is not protected by locking changes made in one thread may not be visible to another thread, or only become visible after an indeterminate interval (esp. on multi-processor machines).

Implementing async API – which is inherently multi-threaded – in a non-threadsafe way is crazy.

This one problem can be worked-around by making Http11AprProcessor methods process(), event() and action() synchronized. This locking protects the ‘comet’ flag. May be similar fix for the NIO connector.

By: billburke

billburke — Thu, 12 Feb 2009 15:07:30 +0000

Paul,

Yes, i flushed the toilet.