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 Wed, 27 Jun 2007 17:29:33 GMT
Remy Maucherat wrote:
> 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:
> I made a number of updates since this proposal (which has been vetoed) 
> was made. The API makes implicit a lot of behaviors which I found are 
> not needed for the end user, and attempts to be fairly high level. In 
> particular, I have rewritten the javadoc, which was self conflicting 
> (due to forgetting to update some wording inherited from TC 6.0). All 
> 6.0.13 API usage should remain compatible (I do expect at least one 
> behavior fix in 6.0.x, though).
> It has the following changes over the 6.0.x branch:
> - additions of three methods in CometEvent (sleep and resume, and the
> ready flag)
> - sleep() delays request processing until either resume() is called, or a
> timeout occurs
> - sleep() also disables read events until resume() is called (in 
> addition to invoking a generic event, resume() also enables read events)
> - resume() allows waking up requests which are "asleep" or waiting for
> an IO event
> - non blocking IO exclusively (with, as an exception to the rule, a 
> switch to blocking IO in very specific cases of synchronous IO 
> operations)
> - no additional data structures
> - new ActionCode: ACTION_COMET_TIMEOUT (which is cleanup),
> ACTION_COMET_RESUME (called by the resume() method),
> ACTION_COMET_SLEEP (called by the sleep() method), ACTION_COMET_WRITE
> (called by the CometEvent.ready() method without the need for an
> explicit callback from the servlet - ready() knows the result of the
> last write, and the servlet is supposed to not attempt any further
> writing if ready() returns false)
> - no additional features, like verification of caller threads (which I
> consider useless)
> - change to o.a.comet package
> I hope I did not forget anything. Certain items could still be changed 
> (like the package name, or the name of the ready() method - the 
> problem with that one is that it does not particularly imply 
> "writing", but OTOH the old canWrite and isWriteable names were quite 
> inelegant).
> I don't want to block development forever, so if this proposal is 
> refused using an outright veto like the previous version of the 
> proposal, I will not block competing proposals using a veto of my own. 
> However, I will most likely stop participating in trunk development 
> (which is not the end of the world since I've been working on Tomcat 
> for pretty much forever, so it could be a good time to move on).
nice ultimatum :)
let me go through both the proposals and look it over. after that I 
suggest we simply have/agree on a majority vote without vetoes to be 
able to move on properly.
in the vote announcement, I think we should simply outline the 
differences so that folks understand that rather than getting confused 
in comet concepts.
you and I can draft that outline together offline,

> 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