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 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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
