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 10:02:18 GMT
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() ) {
} else {

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 
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).
>> 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


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

View raw message