for very small responses you don't need send file, and can just write
the response out to the servlet output stream on an async thread while
the request thread is used to do other stuff in the contains
Filip
Franck Wolff wrote:
I'm not doing file streaming... A typical usage of my implementation
is a Flex based chat application with very small requests/responses.
The important thing for me is: I want the request thread to be reused
for other incoming requests and, as far as I understand long-polling
issues (keeping the request thread busy while waiting for something to
send), this exactly what Tomcat CometProcessor (or Jetty Continuation,
or Grizzly CometEngine, etc.) may offer. Maybe I'm missing something,
but "send file" is not very suitable for chat applications...
Regards, Franck.
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]
---------------------------------------------------------------------
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]
