You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Willem Fibbe <wi...@realworks.nl> on 2011/10/25 11:57:24 UTC

Handling of CometEvents regarding order (Tomcat 6 and 7)

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

Re: Handling of CometEvents regarding order (Tomcat 6 and 7)

Posted by Willem Fibbe <wi...@realworks.nl>.
Hi,

Thanks for your reply.
Just wanted to confirm the following:

On 26/10/2011 11:57, Mark Thomas wrote:
> On 25/10/2011 10:57, Willem Fibbe wrote:
> > 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
> 
> That would be my expectation.
> 
> > However: - in Tomcat 6 I get the CometEnd twice.
> 
> I think the second CometEnd is a bug.

I suspect too. If I read the changelog for Tomcat 7.0.7 for Coyote I see that
this issue has been resolved there.
Maybe something similar is happening in Tomcat 6 also (I verified it for 6.0.29 and 6.0.33).

> 
> > - 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.
> 
> That looks like a bug to me. It may be related to [1]. You might want to
> try running against a locally built 7.0.x to see if the issue is fixed.
> If not, create a bug report.
> 
> Mark
> 
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51881

I built a new Tomcat 7.0.23 and now the second CometRead doesn't occur. Instead,
a CometEnd event is fired properly, so this seems to be fixed.

Thanks,
Willem

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

Re: Handling of CometEvents regarding order (Tomcat 6 and 7)

Posted by Mark Thomas <ma...@apache.org>.
On 25/10/2011 10:57, Willem Fibbe wrote:
> 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

That would be my expectation.

> However: - in Tomcat 6 I get the CometEnd twice.

I think the second CometEnd is a bug.

> - 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.

That looks like a bug to me. It may be related to [1]. You might want to
try running against a locally built 7.0.x to see if the issue is fixed.
If not, create a bug report.

Mark

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51881

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