tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Comet changes
Date Mon, 07 May 2007 15:11:21 GMT
Filip Hanik - Dev Lists wrote:
> ok, here we go, I have thought about this and have two different proposals.
> 1. Add non blocking support to Coyote(In|Out)putStream
>   The servlet can cast request.getInputStream() to a CoyoteInputStream
>   Example:
>   //perform a non blocking read.
>   int read = ((CoyoteInputStream)request.getInputStream()).nbRead(buf);
>   if ( read > 0 ) //we have data
>   else if ( read == -1 ) //eof, in NIO it actually throws EOFException
>   else // move on, read returned 0
>   Same support for writing.
> Basically, the would return the actual number of 
> bytes available to the servlet. not the number of bytes by the socket.
> So the read would have to filter through the chain, and the entire 
> buffer chain would have to support this, I think this is all doable.
> 2. Alternative - expose nbRead through available() method
> If we don't want to expose nbRead or nbWrite by casting to an interface, 
> we could always make
> available() as a non blocking read. available() would return the actual 
> number of bytes for the servlet.
> should available() return >0, then request.getInputStream().read() 
> should return the same number of bytes the return value for available().
> Basically, available() invokes a non blocking read from the socket. then 
> the bytes get passed through the buffers.
> If some buffer requires additional data, it will not invoke a blocking 
> read, instead available() will return 0.
> request.getInputStream().read() - if the top most buffer has data, it 
> will return it immediately, and not invoke the chain down.
> If there is no data, this becomes a regular read.
> This solution lets us do a non blocking read using the existing API, but 
> has no solution for a non blocking write.
> I'd be happy to take a stab at this, and if we don't like it, we can 
> throw it away. I think it is easier for me to show it through code, than 
> through an essay in an email.
> Just give me a feel for option 1 or 2, and I will take one of them, and 
> do it this week, by the end of week I can have one option completed for 
> testing.

This is interesting, and it's giving me some (basic) ideas. I think it 
(at least part 2) is too much about reading, where non blocking and 
blocking are functionally equivalent due to the events which allow 
knowing when read will not block.

In theory, 1 is more interesting, but not with the casting and API 
hacking. It is perfectly legitimate to use Reader/Writer, so adding 
calls which bypass the standard does not seem like a good idea. Maybe it 
could work with an IO control feature on the event (a canWrite method or 
something; the low level would use non blocking writes, buffer a little 
bit, and expect the user to use canWrite to check the result of the last 
real write to the socket; if the user keeps on writing without checking 
canWrite, throw an exception), to go along write events (which is a 
problem: I don't know how to request to be placed in a poller, although 
maybe another method on the event could work), and maybe it would be enough.

 > got it, the extra bytes, if that is a new request, ie "GET /
 > HTTP/1.1..." will that work?

Yes, that's pipelining. The extra bytes are supposed to be a new request.


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

View raw message