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... Christophe
-----Message d'origine----- De : Remy Maucherat [mailto:[EMAIL PROTECTED] 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 = is.read(buf); 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 event.close(); return; } } while (is.available() > 0); Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
