tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
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

Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message