tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java
Date Fri, 16 Jun 2006 23:03:59 GMT
Filip Hanik - Dev Lists wrote:
> what part, the check in or the feature set?

The commit.

> the check in, fixes data transfer by doing comet style, ie, both client 
> and server can "push" data, and working around the HTTP request/response 
> pull model.
> most containers only implement "server async push" but not the client 
> ability to do the same.
> did you have something else in mind?

Yes, getting the read event from the poller means the servlet can do one 
blocking read on the socket without blocking. Calling read on the input 
stream (if the buffer was empty) will do a blocking read on the socket. 
Note that the content delimitation must still be right (maybe that's why 
want to reset the remaining bytes) since using Comet isn't an excuse to 
break the HTTP protocol: you basically have to use chunking on input (or 
use a big content-length - that's what I did in my testing, it's a cheap 
trick).

Then the read method in the servlet must use the algorithm than I used 
in CometServlet:
         InputStream is = request.getInputStream();
         byte[] buf = new byte[512];
         do {
             int n = is.read(buf);
             if (n > 0) {
                 // Do something with the data
             } else if (n < 0) {
                 return false;
             }
         } while (is.available() > 0);
         return true;
So always do at least one read, then continue reading as long as the 
buffer isn't empty.

Rémy

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


Mime
View raw message