tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Comet changes
Date Wed, 09 May 2007 11:06:05 GMT
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>> I agree, but I don't understand how you can know if you can write 
>> without a write polling. If there are no events on read, I have the 
>> impression writing could be suspended for an indefinite amount of 
>> time. So if it works, I am fine with this process.
> In NIO, you basically can call SocketChannel.write anytime you want, it 
> will return 0 if you can't. At the time of returning 0, you simply 
> register it with the poller so that the poller notifies you when a 
> SocketChannel.write actually will succeed. ie, you don't need a poller, 
> you could do a spinning SocketChannel.write until it succeeds, of course 
> this will suck up your CPU. Does that make sense?

So it uses a poller automatically, and the WRITE event would be sent 
when the socket is signaled by the poller, then. This is very similar. 
The only problem is that it could cause sync issues, since the servlet 
doesn't know for sure when the write poller is used.

>> I don't want to do any special funky tracking of writes in the APR 
>> connector, so I disagree with this (feel free to keep it in the NIO 
>> connector if you want to, I'm fine with that). It's also a gratuitous 
>> action which does not provide a real benefit.
> funky tracking? ie, as keeping track of timeouts? Not sure how you are 
> gonna implement "per-connection" timeouts without it?
> Definitely a write should not be indefinite, it should timeout, just 
> like a servlet write does today for servlets.

There is a timeout for write in blocking mode, but not in non blocking 
mode. The timeout is tracked by the poller structure, but mostly 
concerns read events, so it is possible for a socket to timeout when 
there are no read events, even if there is write activity on the socket.

> What I am saying is that we shouldn't allow the servlet to do a 
> event.getHttpServletRequest().getInputStream().read() if the socket is
> registed for a READ event. non blocking mode is fine, as you can 
> instantly return a 0 if that is the case. Blocking mode, when the poller 
> wakes up,
> the async thread will most likely get the data, then the READ event will 
> proceed into the CoyoteAdapter on the worker thread, and get blocked in 
> the
> and voila, you are screwed.

Hmmm, you mean you're as screwed as in a regular servlet ;) Since Tomcat 
is not a cute non blocking server that uses two threads, this does not 
seem to be the end of the world.

What I said is that with APR you can have non blocking reads and writes, 
or blocking reads and writes, but mixing is not possible.


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

View raw message