Re: CometProcessor questions
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
Re: CometProcessor questions
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
Re: CometProcessor questions
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,
Re: CometProcessor questions
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
Re: CometProcessor questions
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: [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]
Re: CometProcessor questions
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
Re: CometProcessor questions
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]
Re: CometProcessor questions
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]
Re: CometProcessor questions
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]
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
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]
