tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Comet changes
Date Wed, 09 May 2007 13:36:38 GMT
Remy Maucherat wrote:
> 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.
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.
>
>>> 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.
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.
>
>> 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 CoyoteAdapter.read
>> 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.
I hear you, NIO only has non blocking, and we "fake" the blocking mode. 
I prefer to do the read non blocking too.
I'll start working on this right now, and see where I get. I think we 
are thinking along the same lines by now, and it's just a matter of fine 
tuning the different connectors and get the shared code to work 
consistently.

Filip

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


Mime
View raw message