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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  • Re: Comet changes Filip Hanik - Dev Lists

Reply via email to