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 17:13:32 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> true. lets see how it pans out in actual code, that might change our 
>> perspective.
>>
>> I was toying around with an alternative idea too, disallow any read 
>> or write all together unless it is done on a worker thread. gives us 
>> complete control, easier to implement.
>>
>> public void CometEvent.notify(int operations);
>>
>> operations = READ | WRITE | NOW;
>>
>> READ - this is what we do now under the covers, this would give the 
>> user the control, basically means, notify me when there is data to read
>> WRITE - notify me when I can write data
>> NOW - send me a worker thread my way, so that I can safely initiate a 
>> blocking or non blocking read or write.
>
> Ok, so it would call notify(WRITE) when the write "available" flag 
> becomes false. Also, do you have any idea of another name for the 
> "notify" method ?
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.

There is tons of use cases here, I wanted to point out another, where it 
is legal for a user thread to read/write.

1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(NONE) - dont register me for any events
4. Servlet Background thread calls 
CometEvent.getHttpServletRequest().read() - could return 0 if no data is 
available
5. Servlet Background thread calls 
CometEvent.getHttpServletResponse().write()

Servlet can call CometEvent.canWrite(), if returns false, subsequent 
request to write will throw an exception
When write has been completed, CometEvent.NOTIFY/WRITE_COMPLETE is sent 
to CometProcessor.event

One more use case, similar to above, but blocking

1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(true);
3. Servlet calls CometEvent.notify(NONE) - dont register me for any events
4. Servlet Background thread calls 
CometEvent.getHttpServletRequest().read() - will not return until data 
is available
5. Servlet Background thread calls 
CometEvent.getHttpServletResponse().write() - will not return until all 
data has been written



Is this too convuluted? We could also relax on the first use case, that 
when a CometEvent.NOTIFY/WRITE event arrives, the servlet doesn't have 
to write right away,
but actually can invoke write using a background thread.

Another use case, the servlet wants to close down the connection
1. CometEvent.notify(NOW)
2. CometProcessor.event(CometEvent.NOTIFY/NOW)
3. Servlet calls CometEvent.close

do you feel like we are spinning circles, starting over or simply making 
it too complex?
Filip

So main difference, Comet

Filip



> 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