Hi,
I'm developing Tomcat/Comet support for Granite Data Service
<http://www.graniteds.org> (Flex clients) and I've got few questions
about CometEvents processing. Basically, my implementation is based on
the Bayeux protocol (long-polling only) and two connections
(command/tunnel) are opened for each clients (producer/consumer). I use
a thread pool in order to dispatch received messages to each consumer
subscribed to the relevant topic. Here are my questions:
1. What should happen exactly if Tomcat send a timeout event when the
current event (ie: a previous BEGIN event whose request input stream was
fully read when it was received) is used for writing a response? Is this
previous BEGIN still valid and may be used to write the response? If
not, should it be close right away and may I use the timeout event
instead or should I wait for a next BEGIN event? Is it the same event
instance whose type/subtype has changed?
2. Tomcat send me sometime (rather rare but it happens) invalid END
events (getHttpServletRequest() issues a NullPointerException). I'm just
trying by now to close them and it don't affect my application behavior
but I'm wondering why those invalid event aren't thrown away by Tomcat
from the beginning and what should be done exactly with them?
3. I'm never receiving any ERROR event except for TIMEOUTs. I would be
of course very interested in CLIENT_DISCONNECT events but I couldn't
find any case where Tomcat would send me this handful event... I was
expecting this event to be raised when the client app is closed or the
net connection broken but Tomcat just stops sending me TIMEOUT events.
It may be useful to say that I'm using APR and not NIO...
3. Would it be possible to use the Tomcat pool thread for sending the
responses instead of creating and managing my own thread pool (I'm using
standard Runnable objects submitted to my own pool but I could submit
them to any other thread pool as well)?
4. Under stress tests (12 clients sending 10 messages/sec. while
listening for the same topic, ie: they may get 12*10 messages/sec., but
some of them (~5-10) are generally packaged in the same response),
asynchronous read doesn't work anymore: a full read of the input stream
must be done on the BEGIN event, otherwise, it seems that most incomming
requests are lost... I didn't try to figure out what's going on but, as
a matter of fact, asynchronous read seems to be broken on heavy load
(just informative, I can use full read on the begin event).
Regards, thanks in advance for any reply,
Franck.