Costin Manolache wrote:
setTimeout() is not optional (the javadoc is out of date, sorry), there
was an agreement on that earlier. Timeout sets the connection timeout,
which is most likely useful even if there are events. It's quite
possible sleep could use a timeout argument (I think calling setTimeout
is more or less mandatory when using sleep, and OTOH calling setTimout
is not as important otherwise).
Ok - then sleep needs the extra argument, and will mean same as
Thread.sleep(),
but
not-blocking ?
This sleep is a non blocking call, and instructs the connection to "do
nothing until I wake you up (or a timeout occurs, of course)".
Although the read event indicates there's data to read, isReadable
indicates if it is possible to continue reading.
My understanding was that the InputStream in request is used for actual
reading -
and available() could do the same thing. What is the difference then
between
the 2 ?
isReadable is the same as is.available (and reader.ready). It's there
for a bit of symmetry after adding isWriteable, which may or may not be
useful, and I didn't care about it.
isWriteable indicates if the last write operation managed to write more
than 0 bytes. If the last write wrote 0, then isWriteable will return
false, so the servlet knows it should stop writing on this connection
for now (since it cannot accept any output at the moment). Later on, the
servlet will receive a write event, and can resume writing.
I'm still a bit confused about this - my understanding was that write event
means the
previous buffers were written, and you can write more. There are some
buffers
on the OS side as well as buffers on the connector side.
Yes, it means that: the servlet gets a write event, which means it can
start writing again.
What do you mean by 'managed to write more than 0 bytes' - the write in the
OutputStream
can go to some of the buffers, or to the client. I assume you don't mean
the
client ( due to TCP
delays ).
I was talking about the actual write on the socket (in APR, it's done in
InternalAprOutputBuffer.flushBuffer), which may return 0. At the servlet
layer, as per the contract of the OutputStream API, is must write
everything or fail, and this isn't going to change.
- If doing synchronous writes inside some event (either a read or
callback event, most likely), then both blocking and non blocking mode
make sense. Some servlets may prefer to use blocking mode although it
could be holding a thread for a while (for example if the idea is only
maybe a 'waitForEvent()' method to allow a servlet to block if he wants
to ?
Or is sleep() supposed to do this - I'm not sure from the comments if
sleep() will
block or just triger an event when the interval expires ?
Sleep will by itself only trigger timeout events (the method call itself
will return immediately). The servlet can use the callback method to
trigger an event before the timeout occurs.
You mean sort of 'notify()' - i.e. someone calls callback() and will
trigger the
servlet to be executed, interrupting any sleep or wait ?
Originally, this was indeed supposed to be called "notify", but it's not
possible due to Object.notify :( If you have another name to suggest to
replace "callback" ...
In general ( both versions):
> - it would be great to move it from o.a.catalina to org.apache.comet
It's a possibility.
I think more comments and examples ( and maybe better names ) would be
great.
I think there's going to be some code using Comet soon.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
