Re: comet events and connections
Exception in thread Thread-17 java.lang.NullPointerException at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:84) at com.mrtattle.tcniotest.CometServlet$Transport.close(CometServlet.java:42) at com.mrtattle.tcniotest.CometServlet$1.run(CometServlet.java:117) at java.lang.Thread.run(Thread.java:613) yes, calling close on the begin event, and then expecting the CometEvent object to still function is a misuse of the API I don't konw if it makes any difference, but: I am not calling close in the begin event! My example never does so because I know that in this case the io will never get in comet mode. Obviously my pseudo code was misleading. Step by step example (no keep alive) 1. Request Thread A triggers begin event. 2. On the begin event a new Worker Thread is startet. That worker gets access to the event object 3. Request Thread A leaves CometServlet.event method 4. Worker Thread sends message 1 5. Another Request Thread B closes event 6. Request Thread C triggers end event. (because of no keep alive) -- Recycling of req res From that moment on event.close causes an NPE. In my example the Woker Thread eventually tried to close the event again. Same example (keep alive) 1-5. Same as above 6. Response is closed 7. Worker thread writes next messages to response (no exception) 8. Worker thread calls event.close() (no exception) Wait a bit 9. Keep alive timeout - END I know that you can just wrap the event object into some facade and keep track of its state to prevent all this. It just whished it would behave it bit different. And whishes are free right? Filip Hanik - Dev Lists wrote: Daniel Doubleday wrote: I don't think that a event.close() call should throw a NPE when the event is already closed. But I would rather catch an exception when I am writing to response object that has been closed. that is possible to do, do you have the stack trace of the NPE? Here is the stack trace: Exception in thread Thread-17 java.lang.NullPointerException at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:84) -- View this message in context: http://www.nabble.com/comet-events-and-connections-tf3647567.html#a10196859 Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: comet events and connections
Well, anyway the lifecycle should be well-defined, and I doubt that it currently is well-defined. If I try to find a better name for class CometEvent which reflects the lifecycle of it's instances according to the current implementation, the name CometRequest fits much better than the name CometConnection, but it does not fit perfectly yet. Have a look at my posting in thread 'Memory Leak with Comet' for more details. Matthias -Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 1:18 AM To: Tomcat Users List Subject: Re: comet events and connections I think that the comet api represents a socket connection. The event life cycle is bound to the connection life cycle. You get an END (or ERROR etc) when the connection gets closed. But when you are writing something that still looks like a servlet you would expect that the event life cycle is bound to the request / response model. As soon as the response is closed you would expect an END event. It's fine to have expectations, but that's not going to happen. It is fine to compare with a Servlet, but the only thing that cannot be compared (and somehow is the thing you apparently want to compare) is evidently the lifecycle, which is completely different. Rémy - 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: comet events and connections
On 4/26/07, Reich, Matthias [EMAIL PROTECTED] wrote: Well, anyway the lifecycle should be well-defined, and I doubt that it currently is well-defined. If I try to find a better name for class CometEvent which reflects the lifecycle of it's instances according to the current implementation, the name CometRequest fits much better than the name CometConnection, but it does not fit perfectly yet. This is your idea of the design and usage scenarios, and it's perfectly legitimate if it fits your ideas better. However, the changes you suggested are not going to be made in Tomcat. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
comet events and connections
Hi this post is a follow up from http://issues.apache.org/bugzilla/show_bug.cgi?id=42198 where this post does not belong. I want to find out if my understanding of the comet api in tomcat is right concerning how connections are handled and event are triggered. I have a very simple test webapp which streams a couple of messages to a browser via XHR. The pseudo code of the comet servlet looks looks like this: switch (event) case BEGIN: start worker thread which will post messages up the response and call event.close when finished case END: case ERROR: signal worker thread that it must stop sending messages case READ: throw IOException // expect that ERROR is triggered Now when opening the streaming connection I can specify if the connection should be kept alive or closed after the request has finished. This done be setting the response header Connection: close. When using a Keep-Alive connection there is no instant END event triggered when event.close() is called. Thats because the connection itself is not closed. After a while when the keep alive connection times out the client will release it and the END event will be triggered. When not using Keep Alive the end event is triggered instantly after the event.close() method is called. The response has been committed at this time and will be recycled after this method call. The problem is that the comet event object is in two different states although the same method has been called. On one hand, when the underlying objects have been recycled a call to method.close() yields a NullPointerException and on the other hand, when the response has been closed but the connection is still there an asynch process can continue to write to the response stream without being notified that it's writing nowhere. In my opinion in should be the other way round: I don't think that a event.close() call should throw a NPE when the event is already closed. But I would rather catch an exception when I am writing to response object that has been closed. Maybe I am getting something wrong, but I think that the api should rather reflect a request model, where the end event is triggered when the response is closed. Now it seems that it more reflects the connection model. I am sure that one can live with it as it is though. Or maybe I'm just wrong? Cheers, Daniel -- View this message in context: http://www.nabble.com/comet-events-and-connections-tf3647567.html#a10187852 Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: comet events and connections
Daniel Doubleday wrote: Hi this post is a follow up from http://issues.apache.org/bugzilla/show_bug.cgi?id=42198 where this post does not belong. I want to find out if my understanding of the comet api in tomcat is right concerning how connections are handled and event are triggered. I have a very simple test webapp which streams a couple of messages to a browser via XHR. The pseudo code of the comet servlet looks looks like this: switch (event) case BEGIN: start worker thread which will post messages up the response and call event.close when finished case END: case ERROR: signal worker thread that it must stop sending messages case READ: throw IOException // expect that ERROR is triggered Now when opening the streaming connection I can specify if the connection should be kept alive or closed after the request has finished. This done be setting the response header Connection: close. Correct. When using a Keep-Alive connection there is no instant END event triggered when event.close() is called. Thats because the connection itself is not closed. After a while when the keep alive connection times out the client will release it and the END event will be triggered. Depends, you can receive an ERROR or a READ event. The NIO connector detects the disconnect as a READ event. in your READ you must do request.getInputStream().read(), and you should check for -1 as a return value. When not using Keep Alive the end event is triggered instantly after the event.close() method is called. The response has been committed at this time and will be recycled after this method call. In your code example, doing a close in the BEGIN event, you connection is never marked as a Comet in the underlying IO layer. The problem is that the comet event object is in two different states although the same method has been called. On one hand, when the underlying objects have been recycled a call to method.close() yields a NullPointerException and on the other hand, when the response has been closed but the connection is still there an asynch process can continue to write to the response stream without being notified that it's writing nowhere. Its your responsibility to keep track of references. You can turn off Tomcat's reuse of facade objects, see a post earlier today or yesterday. In my opinion in should be the other way round: I don't think that a event.close() call should throw a NPE when the event is already closed. But I would rather catch an exception when I am writing to response object that has been closed. that is possible to do, do you have the stack trace of the NPE? Maybe I am getting something wrong, but I think that the api should rather reflect a request model, where the end event is triggered when the response is closed. Now it seems that it more reflects the connection model. I am sure that one can live with it as it is though. not sure I understand this and what you are trying to get at. Filip Or maybe I'm just wrong? Cheers, Daniel - 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: comet events and connections
I don't think that a event.close() call should throw a NPE when the event is already closed. But I would rather catch an exception when I am writing to response object that has been closed. that is possible to do, do you have the stack trace of the NPE? Here is the stack trace: Exception in thread Thread-17 java.lang.NullPointerException at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:84) at com.mrtattle.tcniotest.CometServlet$Transport.close(CometServlet.java:42) at com.mrtattle.tcniotest.CometServlet$1.run(CometServlet.java:117) at java.lang.Thread.run(Thread.java:613) Maybe I am getting something wrong, but I think that the api should rather reflect a request model, where the end event is triggered when the response is closed. Now it seems that it more reflects the connection model. I am sure that one can live with it as it is though. not sure I understand this and what you are trying to get at. I think that the comet api represents a socket connection. The event life cycle is bound to the connection life cycle. You get an END (or ERROR etc) when the connection gets closed. But when you are writing something that still looks like a servlet you would expect that the event life cycle is bound to the request / response model. As soon as the response is closed you would expect an END event. Filip Hanik - Dev Lists wrote: Daniel Doubleday wrote: Hi this post is a follow up from http://issues.apache.org/bugzilla/show_bug.cgi?id=42198 where this post does not belong. ... not sure I understand this and what you are trying to get at. Filip -- View this message in context: http://www.nabble.com/comet-events-and-connections-tf3647567.html#a10190519 Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: comet events and connections
On 4/25/07, Daniel Doubleday [EMAIL PROTECTED] wrote: Here is the stack trace: Exception in thread Thread-17 java.lang.NullPointerException at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:84) at com.mrtattle.tcniotest.CometServlet$Transport.close(CometServlet.java:42) at com.mrtattle.tcniotest.CometServlet$1.run(CometServlet.java:117) at java.lang.Thread.run(Thread.java:613) This means (quite predictably) the request is done and has been recycled, and you should probably add syncs here and there. I think that the comet api represents a socket connection. The event life cycle is bound to the connection life cycle. You get an END (or ERROR etc) when the connection gets closed. But when you are writing something that still looks like a servlet you would expect that the event life cycle is bound to the request / response model. As soon as the response is closed you would expect an END event. It's fine to have expectations, but that's not going to happen. It is fine to compare with a Servlet, but the only thing that cannot be compared (and somehow is the thing you apparently want to compare) is evidently the lifecycle, which is completely different. Rémy - 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: comet events and connections
Daniel Doubleday wrote: I don't think that a event.close() call should throw a NPE when the event is already closed. But I would rather catch an exception when I am writing to response object that has been closed. that is possible to do, do you have the stack trace of the NPE? Here is the stack trace: Exception in thread Thread-17 java.lang.NullPointerException at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:84) at com.mrtattle.tcniotest.CometServlet$Transport.close(CometServlet.java:42) at com.mrtattle.tcniotest.CometServlet$1.run(CometServlet.java:117) at java.lang.Thread.run(Thread.java:613) yes, calling close on the begin event, and then expecting the CometEvent object to still function is a misuse of the API Maybe I am getting something wrong, but I think that the api should rather reflect a request model, where the end event is triggered when the response is closed. Now it seems that it more reflects the connection model. I am sure that one can live with it as it is though. not sure I understand this and what you are trying to get at. I think that the comet api represents a socket connection. The event life cycle is bound to the connection life cycle. You get an END (or ERROR etc) when the connection gets closed. But when you are writing something that still looks like a servlet you would expect that the event life cycle is bound to the request / response model. As soon as the response is closed you would expect an END event. That's pretty much how it is Filip Filip Hanik - Dev Lists wrote: Daniel Doubleday wrote: Hi this post is a follow up from http://issues.apache.org/bugzilla/show_bug.cgi?id=42198 where this post does not belong. ... not sure I understand this and what you are trying to get at. Filip - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
