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 14:00:30 GMT
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>> 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.
> this is much lower than the servlet and comet events. when doing 
> socketchannel.write, no poller, or selectors are involved. If there 
> simply isn't space on the buffer, it returns 0.
> At this point, the InternalNioOutputBuffer would register the socket, 
> and the servlet thread would return.
> When the poller detects "write available on socket", it wakes up, 
> internally it would try to write the remaining data from bbuf.
> when all data from bbuf is written, the worker thread then proceeds to 
> signal the servlet with a NOTIFY/WRITE_COMPLETE
> so all the actual non blocking writing is hidden from the user/servlet. 
> and no sync issues should arise since we will follow your suggestion and 
> throw an exception.

Yes, I perfectly understand that, and it mostly works. However, there's 
maybe a time gap for trouble:
- the write returns 0
- the "available" flag for write goes to false
- the socket is put in the write poller
- the stack that lead to the write resolves, and the code returns to the 
servlet; the servlet is supposed to look at the "available" flag, see 
that it false, and stop writing
- meanwhile, the socket lands in the poller (quickly or not), and could 
exit the poller quickly too, which triggers the flush of the leftover 
bytes and the WRITE_COMPLETE event

So there could be a race between the servlet checking the "available" 
flag and the flush, so the flush could be done at the same time as 
another write by the servlet. This is very unlikely (and maybe it cannot 
happen), but this is why I preferred using a method that the servlet 
would be calling after checking the "available" flag.

>> 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.
> yes, with NIO we update this poller structure even during async writes, 
> so if there is write activity on the socket, the socket wont timeout.

Ok, I had understood correctly then. I will not be doing that in APR. 
This would cost many syncs and other operations, which is not acceptable 
just for supporting this "feature".


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

View raw message