tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Comet changes
Date Wed, 09 May 2007 17:42:59 GMT
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.

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


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

View raw message