tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Proposed simplification of CometEvent
Date Fri, 08 Jun 2007 08:57:10 GMT
If you don't care about this stuff, but still read the first line, do 
our community a favor and get involved :)

The API's are pretty much identical,


There are a few differences

 - Remy - same functionality as ServletInputStream.available()
 - Filip - ServletInputStream.available() || 
InternalNioInputBuffer.hasData || 
ie, is readable in my API means that there is some data from the bottom 
layer of the API. Doesn't mean that it would actually result in data to 
a, but most cases it would. The benefit of 
this method is that it actually does check the socket for data in a non 
blocking way if the first two conditions have not been met.
API has been implemented in trunk. so isAvailable() is different, and 
both methods can be used for different purposes

 This functions the same way in both APIs. After playing with the API 
this function is useless unless you have true non blocking writes.
 Why? Well, the function will always return true, unless there is 
another thread writing, but write is not thread safe, so another thread 
should never attempt to write.
 And in a blocking way, isWriteable()->true : write(blocking) : 
isWriteable()->true, always.
 However, in the blocking API, there is a true way to find out if we can 
write or not, and that is by calling CometEvent.register(OP_WRITE), this 
will actually check with the poller
 to see if the network buffer is ready to receive more data and dispatch 
a worker thread.

 - Remy - one time callback from the container on a Tomcat worker thread
 - Filip - same functionality implemented, CometEvent.register(OP_CALLBACK)
I definitely like the register/unregister for events more than I like 
the one time functionality of callback()/sleep().
OP_CALLBACK currently is implemented and working in trunk.
Why do I like register more? Cause we can add new operations in the 
future without changing the API. This leads to more flexibility.
Currently OP_CALLBACK stays registered until it is "unregister"-ed. If 
we wanted to achieve callback() functionality, we can add a 
OP_CALLBACK_ONCE operation or simply change the behavior of existing 
callback, without changing the API.
it is also possible to retrieve the state of a comet connection by 
calling getRegisteredOps, something not available in the sandbox API.

 - Remy - deregister from the READ events
 - Filip - same functionality exists, 
CometEvent.unregister(OP_READ,OP_WRITE,OP_CALLBACK) or simply 
CometEvent.unregister(OP_READ) if nothing else is registered.
Again, I think the trunk API is more flexible, and cleaner. sleep() is 
associated with Thread.sleep() in every programmers head. and doesn't 
really apply to an event based API.
This is implemented in trunk and working.

Conclusion, both APIs are almost identical. I believe the trunk API is 
more flexible and allows for additions of functionality in the future 
without changing the API.
Remy's initial -1 to the trunk was based on the implementation, having 
to synchronize etc. All that has been simplified and removed.

So therefor, the API's are almost identical, I would vote
sandbox API -> -1 -> API is simple but not extensible, names are not 
intuitive as they are not event oriented.
trunk API -> +1 -> API is equally simple, more geared towards event 
based API, more flexible, as I am sure new needs will need new 
operations and events

The only thing not working in trunk at this moment is non blocking, but 
after doing the research, this is a major surgery to try to do within 
the existing buffer/filter API
I'd rather delay such an attempt until we can reach consensus on the API 
and the "simple stuff".

Looks like we are gonna have to have a pancake flipping contest :)


Remy Maucherat wrote:
> Hi,
> I've been working on additions to CometEvent to implement the 
> additional Comet functionality that was agreed upon before creating 
> the "trunk" branch. Although not functional at the moment, I consider 
> it to be developed enough from an algorithmic standpoint to be 
> proposed and reviewed (it is also important to not continue an API 
> fork for too long, since otherwise it would be harder to merge, so 
> some resolution is needed). I went through a few revisions of the API, 
> as more tweaks appeared possible. The idea was to allow the extra 
> functionality without adding complexity or incompatible changes, since 
> this is most likely going to be an interim API.
> The repository is at:
> It has the following changes over the 6.0.x branch:
> - additions of four methods in CometEvent (sleep and callback, and the 
> two flags isRead(Write)able)
> - sleep delays request processing until either callback is called, or 
> a timeout occurs
> - callback allows waking up requests which are "asleep" or waiting for 
> an IO event
> - non blocking IO exclusively in Comet mode, since it now seems to me 
> it is algorithmically equivalent to blocking IO; for read, it has been 
> demonstrated previously; for write, it seems there should always be 
> write events after a properly handled congestion (where the servlet 
> uses isWriteable), since if the servlet does not, it will be best to 
> simply fail-fast the connection using an IOException (the servlet 
> would effectively only handle clients which are "fast enough" if using 
> the Comet API like in Tomcat 6.0, which avoids a lot of issues)
> - isRead(Write)able indicate if data may be read or written (since 
> this is non blocking IO, reading or writing would read or write 0 
> bytes); if it is false and reading or writing is done, an IO exception 
> will be thrown
> - no additional data structures
> - new ActionCode: ACTION_COMET_TIMEOUT (which is cleanup), 
> ACTION_COMET_CALLBACK (called by the callback() method), 
> ACTION_COMET_SLEEP (called by the sleep() method), ACTION_COMET_WRITE 
> (called by the CometEvent.isWriteable method without the need for an 
> explicit callback from the servlet - isWriteable knows the result of 
> the last write, and the servlet is supposed to not attempt any further 
> writing if isWriteable returns false)
> - no additional features, like verification of caller threads (which I 
> consider useless)
> I hope I did not forget anything.
> Comments ? / Votes ?
> Rémy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message