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:31:07 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.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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


Mime
View raw message