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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
