hi Franck, are you using this Bayeux impl?
http://svn.apache.org/viewvc/tomcat/trunk/modules/bayeux/
or do you have your own?
Filip
Franck Wolff wrote:
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.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]