Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
oh crap, we are thinking way different :), I was thinking the other
way around
Here is one event chain
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(READ) - the servlet wants to be
notified when data is available
4. Data arrives on the socket
5. CometProcessor.event(CometEvent.NOTIFY/READ)
6. Servlet calls a CometEvent.getHttpServletRequest().read()
7. Servlet calls CometEvent.notify(READ|WRITE); - this servlet wants
to be notified when it can write or read data
8. CometProcessor.event(CometEvent.NOTIFY/WRITE);
9. Servlet calls a CometEvent.getHttpServletResponse().write(bbuf)
10. Under the hood, write is being done when it can write until the
buffer is empty
11. CometProcessor.event(CometEvent.NOTIFY/WRITE_COMPLETE)
12. Servlet calls CometEvent.notify(WRITE); - notify me when I can
write again
13. Data arrives on the socket again
14. CometProcessor.event(CometEvent.NOTIFY/READ);
so this whole time I thought the notify() method is a call from the
servlet to the container.
The Comet servlet "register" actions it wants to be notified of.
And basically, this way, we disallow any writes or reads from a
"user" thread when the Poller is in use.
Ok, I am running away screaming in horror (and begging for mercy).
It's not acceptable to generate one event, along with plenty of API
interactions, for every write operation. The benefit I wanted to
provide is easy asynchronous writes. For example, let's say you want
to send something on all your connections (which is IMO quite common),
and let's say you have 10000. Having to generate 10000 events and
process each of them using one thread is extremely bad. To summarize,
I don't want to hear about sending write events until one write is
incomplete, and async writes should be allowed.
At this point, I think I will veto any change beyond tweaks to my
earlier proposal (which did not do non blocking IO). It would avoid a
lot of complexity, at least.
ok, this is what I would like to keep from my suggestions
1. CometEvent.notify is a servlet calling container method,not a
callback from the container
2. Introduce a new EventType -> NOTIFY
3. Keep the sub event type -> WRITE_COMPLETE, instead of having to busy
poll CometEvent.canWrite()
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
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
much more straight forward, ja? :)
Filip
Is this too convuluted?
do you feel like we are spinning circles, starting over or simply
making it too complex?
Yes, I think it got a little bit out of hand, thanks for noticing it ;)
Rémy
---------------------------------------------------------------------
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]
