tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Comet changes
Date Thu, 10 May 2007 11:42:50 GMT
ok, changes are in,

there is one inconsistency,
currently READ is a main type, while WRITE is a subtype of NOTIFY
thoughts on consolidate these? ie NOTIFY/READ or make WRITE a main type

by no means is this set in stone, and as we go along and discover 
problems or semantics issues, we can make any adjustments that are needed.


Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> 1. CometEvent.notify is a servlet calling container method,not a 
>>> callback from the container
>> The servlet calls the "notify" method, right ?
>>> 2. Introduce a new EventType -> NOTIFY
>>> 3. Keep the sub event type -> WRITE_COMPLETE, instead of having to 
>>> busy poll CometEvent.canWrite()
>> I'd like to know where this "busy poll" for CometEvent.canWrite() 
>> comes from ;) That flag would be used like available is, such as:
> we're thinking along the same lines.
> I was more thinking
> if ( event.isWriteable() ) {
>  os.write(data);
> } else {
>  event.register(WRITE);
> }
> so instead of WRITE_COMPLETE event, your idea of letting the servlet 
> know when it can receive more data NOTIFY/WRITE, is essentially the 
> same message.
> so I'm happy to do it this way.
> "while" or "if" depends on the app of course.
> The "busy poll" thoughts came up because I thought you were against 
> any event notification.
>> while (event.canWrite()) { {
>>   os.write(randomData);
>> }
>> _notify(WRITE);
>> I am not ok to have to wait for an event following each write, since 
>> it has a huge cost (the canWrite flag is there to be able to do it 
>> only when it is needed).
> agreed.
>>> 4. Introduce CometEvent.setBlocking(true|false)
>>> 5. CometEvent.notify(NOW) to spawn an instant thread, for example, 
>>> changing blocking -> non blocking and the other way around should be 
>>> done on a Tomcat worker thread, too many race condition can occur 
>>> from doing it async with a background thread. Also useful for 
>>> blocking writes when that is desired
>> Changing blocking mode in the middle is a bit extreme, I think.
> it is. For rev 1, lets only allow it during the "BEGIN" event, and 
> throw an exception if it is done anytime outside of that.
>>> and third scenario, useful when you want to end the request, but 
>>> don't want to wait for an IO event or a timeout.(event.close() -> 
>>> event.notify(NOW) or the other way around)
>>> EventType-> NOTIFY SubEventType->NOW
>> "notify" is not possible as a method name, any ideas ? I am ok with 
>> using the proposed notify subtypes.
> I suggest these methods
> event.configure - instead of setBlocking - as I'd like to set a flag 
> to not register with poller as well, so we can use int options
> event.register - instead of notify
> event.isWriteable - instead of canWrite
>> Overall, I would be happier to not be doing non blocking IO. There 
>> will be a lot of ifs in the code, and it will be pretty complex to test.
> welcome to my world :) NIO implementing non blocking for a blocking API.
> I'll have the API changes in in another 2 hours
> Filip
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message