Hi,
We've been building (separate) comet servlets for Tomcat 6 and 7 (following the
corresponding AIO documentation on
http://tomcat.apache.org/tomcat-6.0-doc/aio.html and
http://tomcat.apache.org/tomcat-7.0-doc/aio.html).
After inspecting the order of CometEvents that are fired, I've found different
results for Tomcat 6 and 7 and would like to verify if this behaviour is
correct. There are 2 situations to concern:
[1] - a Comet request is opened, but the server doesn't write to it, which
leads to a servlet Timeout (set to 1 minute)
[2] - a Comet request is opened and before the timeout, data is written over
the connection to the client and the CometEvent is closed using event.close()
It should be noticed that Comet requests are initiated with the POST method
(the client POSTs meta-data regarding the connection only once on opening the
request). The connection is merely used for server-side push (i.e. server ->
client, not client -> server).
In all tested Tomcat versions, the Timeout of the Comet servlet [1] is
represented with these CometEvents:
1. - CometBegin
2. - CometRead (the POST-data)
3. - CometError (the Timeout that occurs -> EventSubType.TIMEOUT)
This seems to be correct.
Now actually writing data over the connection, i.e. [2]:
In Tomcat 6 (tested on 6.0.29 and 6.0.33, both Linux), the lifecycle of a Comet
request seems to be as follows:
1. - CometBegin
2. - CometRead (the POST-data)
... data being written over the connection, then event.close()
3. - CometEnd (event.close() probably triggers this CometEnd (EventSubType ==
null))
4. - CometEnd (why is this CometEnd also triggered? (EventSubType == null))
In Tomcat 7 (tested on 7.0.22 on Linux and 7.0.19 and 7.0.20 on Windows):
1. - CometBegin
2. - CometRead (the POST-data)
... data being written over the connection, then event.close()
3. - CometRead (Ok, kind of strange I guess, however the docs say that some
client disconnects are represented by a CometRead)
Now for my questions:
1 - Can anybody confirm this lifecycle? If I read the AIO documentation, a
typical lifecycle would be:
Begin -> Read -> ... -> Error or End
However:
- in Tomcat 6 I get the CometEnd twice.
- in Tomcat 7 I get a second CometRead, but never a CometError or
CometEnd (see next question)
2 - Related to the first question, how should we handle the second CometRead
event in Tomcat 7? We tried two ways:
- check whether the CometEvent was already closed, and if so just return
out of the method
- just try reading from the InputStream always when CometRead occurs.
This means that the second CometRead results in an IOException ("Stream
closed") (even reading a single byte)... however, Tomcat should catch this and
should fire a CometError event.. yet, we don't see this CometError triggered in
this case.
Is it Tomcat that does not follow this typical lifecycle or behaviour or are we
missing something that we should be doing?
Thanks in advance for any feedback!
Willem
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
