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]
