hi Franck,
Franck Wolff wrote:
Hi Filip,
Ok, my (partly) mistake. I've missread this comment:
///GET method or application/x-www-form-urlencoded/
in BayeuxServlet.checkBayeux...
Anyway, I can't change everything now and I need to read the request
input stream (I'm getting AMF3 binary data), not to get a request
parameter as in:
if you need to stream up data, no need to do that using Bayeux, just use
a regular servlet for that.
String message =
cometEvent.getHttpServletRequest().getParameter(Bayeux.MESSAGE_PARAMETER);
When you speak about patches in the trunk, does it apply to comet
support in general or the Bayeux impl, and what issue is it intented
to fix? Will it be available in 6.0.19 and (approximatively) when?
both, some fixes are for the Comet behavior and Bayeux will exist as an
independent module.
There are a few fixes already applied in the 6.0.x branch, and a couple
of more are pending, waiting for review
Filip
Thanks for your reply,
Franck.
it only does POST, no GET messages,
there is a patch pending (and one already applied) for 6.0 when it
comes to comet, so testing with trunk would be best
Filpi
Franck Wolff wrote:
Hi again,
I just checked the Bayeux in Tomcat and it cannot work for me: it
seems to only support GET request (am I wrong?)...
Regards,
Franck.
Hi,
Thanks for your reply!
I didn't know about this Bayeux impl in Tomcat, so I developed my
own implementation (that is not strictly conforming to the spec,
just very close).
I'm going to check this module and see if I can get some hints.
What about the CLIENT_DISCONNECT event sub type? Any hints?
Regards,
Franck.
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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]