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 Tue, 08 May 2007 10:52:31 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> That's the easy part: the bytes are kept in the usual socket buffer, 
>>> which will be flushed when the connection comes back from the write 
>>> poller, just before invoking the write event.
>> not so easy, if the servlet invokes write again, you have concurrency 
>> issues. first you register the socket for a WRITE event with the 
>> poller, at the same time an async thread tries to write more data.
> That doesn't look like much of a problem to me. The user in that case 
> would be writing in a situation where canWrite is false (since the 
> data hasn't been written yet), which is an error. To resume writing 
> stuff after canWrite becomes false, the servlet would have to wait 
> until it gets the write event.
and that's my issue, no we are adding a "new hidden API", ie, we are 
changing the behavior of the old blocking API.
I like that even less than doing a cast to invoke nbWrite on 

outputstream.write should always do a blocking write and return only 
when all data is written, not be transformed by the canWrite behavior.

if you dont like casting, then simply adding nbRead/nbWrite to the 
CometEvent interface solves all problems.
no need for canWrite, as in the scenario where canWrite returns false, 
nbWrite returns 0. same behavior. just simpler and more consistent with 
Java and it's non blocking features.

> Rémy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message