tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Pierret" <>
Subject RE: Comet API and InputStream.available()
Date Wed, 24 Jan 2007 18:47:41 GMT
OK, I understand your rationale.
It is a tough job to retrofit asynchronous IOs in a synchronous framework like the "servlet
specification" and you did great given the constraints !
Continue the good job...

-----Message d'origine-----
De : Remy Maucherat [] 
Envoyé : mercredi 24 janvier 2007 14:48
À : Tomcat Developers List
Objet : Re: Comet API and InputStream.available()

Christophe Pierret wrote:
> Here is what I understood:
> Assumption #1: ================ When you receive a 
> CometEvent.EventType.READ event, you can always read() at least one 
> byte from the request's InputStream without blocking.
> Is this correct ? If not correct, then this mail goes directly to 
> trash (and sorry for the inconvenience...)

It's not 100% correct: you may do one blocking read without waiting for client input (as the
poller signaled data was available). However, the InputStream that is given to you in the
Servlet is a buffered stream that has no relation with the socket. I don't like the idea of
returning "1", which is a hack. The only non hack way of doing it is to do the read somewhere
(in CometAdapter.event) to fill the buffer of the input stream before calling the Servlet.

At the moment, I use this read method (which is compatible with both behaviors of available())
in the chat servlet from the examples:
         do {
             int n =;
             if (n > 0) {
                 log("Read " + n + " bytes: " + new String(buf, 0, n)
                         + " for session: " + request.getSession(true).getId());
             } else if (n < 0) {
                 // Error: do cleanup
         } while (is.available() > 0);


To unsubscribe, e-mail: For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message