You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Franck Wolff <fr...@graniteds.org> on 2008/11/17 15:23:41 UTC

CometProcessor questions

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.

Re: CometProcessor questions

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------- 
>>>>>>>>
>>>>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------- 
>>>>>>>
>>>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Franck Wolff <fr...@graniteds.org>.
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: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------- 
>>>>>>>
>>>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Franck Wolff <fr...@graniteds.org>.
Hi Filip,

Hum... I need a CometProcessor (long-polling) for data push, even if 
requests/responses are encoded in AMF3. 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?

And what about the CLIENT_DISCONNECT event?

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.

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: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Franck Wolff <fr...@graniteds.org>.
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:

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?

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: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


Re: CometProcessor questions

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Franck Wolff <fr...@graniteds.org>.
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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Franck Wolff <fr...@graniteds.org>.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: CometProcessor questions

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org