Franck Wolff wrote:
Hi Filip,
Hum... I need a CometProcessor (long-polling) for data push, even if
requests/responses are encoded in AMF3.
you can do this, that's ok. Not as efficent as using send file, which
you could write your own long poll servlet to do
(see DefaultServlet.java how to initiate a send file)
Everything is based on subscription to topics (Consumer) & messages
publication (Producer) and, while it could work with a standard
servlet (polling), it won't be efficient.
Anyway: my code mostly work, I'm just experiencing unexpected
behaviors on (rather) heavy load: some events are invalid
(getHttpRequest throws a NPE) and I'm wondering what should be done
with those events (I currently try to close them). I'm also wondering
what should be done when a TIMEOUT is received when a previous BEGIN
event is used for writing a response: for example, after a 20s (APR
timeout), it is possible (but rare) that a message is received (from
another client) and dispatched so a previous BEGIN event (long-polling
again) is used when writing the response. In that case, is the BEGIN
event still valid?
shouldn't be, you could use the NIO connector and control the timeout
behaviour using CometEvent.setTimeout
And what about the CLIENT_DISCONNECT event?
disconnect is just a subtype, its would be captured by a
CometEvent.EventType.ERROR or CometEvent.EventType.END event.
a client disconnect really means nothing in the bayeux world though, the
client has to explicitly send a "I'm done" message or the server has to
have a separate timeout, unrelated to socket events.
I'm sorry to ask the same questions again but I would love some
answers ;-)
I'll try Tomcat trunk when I'll have some time.
please do, its easy to build
ant download
ant
and the tomcat build is in output/build
Regards,
Franck.
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]
---------------------------------------------------------------------
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]
