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 Wed, 09 May 2007 19:19:20 GMT
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.
sounds good, lets go for it, at this time we need something to target, 
should it not work out, we'll figure that out later
>> 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 ;)
I know, sometimes my "take over the world" grand ideas are a little too much


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

View raw message