tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Proposed simplification of CometEvent
Date Wed, 13 Jun 2007 19:28:09 GMT
On 6/13/07, Remy Maucherat <remm@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message