On 6/13/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
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)".
Please add this to the javadoc :-)
And maybe call it 'setTimerEvent(timeMillis)' or something like that - to
avoid
confusion with Thread.sleep() which is blocking the thread.
IMHO it would be very nice to also have a blocking waitForEvent(timeMillis)
-
as an alternative to adding blocking mode as in the trunk.
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.
Why not call it available() and return the same as the servlet method ? I
think
it's ok to have 'shortcuts' in the CometEvent - even read()/write() methods
that
would expose more efficient ways to send/get data than the InputStream.
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.
Where 'write everything' means 'maybe buffer some of it at OS or java
layer'.
Could you add more javadocs on how much can you expect to write if
isWriteable() returns
true ? Since the OutputStream method doesn't support partial writes - I
suppose
this would help more than isWriteable.
- 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" ...
Well - servletNotify() or servletWakeup() or sendCometEvent() ?
Costin
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]
