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