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: Proposed new CometEvent.notify method
Date Thu, 03 May 2007 15:56:58 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> a) make sure it is not registered for READ event
>> b) call event.close()
>> c) call event.notify() - yields a END or NOTIFY event
>
> You need to be doing stuff in your servlet somewhere in between too.
yes, that's what I meant, this would be in the "UserServlets that 
implements CometProcessor"
>
>> 1. Change "boolean comet =" to "int comet =" or to a list of enum, 
>> based on if you want to register for a read with the poller or to not 
>> have any poller interaction
>>   So reuse the same code we have, and at the end decide what list to 
>> add the connection too, the Poller.READ or Poller.NOOP (pardon my own 
>> names:)
>>   The CometProcessor could use the CometEvent to decide during the 
>> BEGIN event, whether to register for READ or not.
>
> Unfortunately, I will have to redo the timeout code for APR, since it 
> turns out to be too limited (IMO).
sure thing
>
>> 2. I'd like to expand on available, is it possible to at the very 
>> bottom InternalXXXInputBuffer.SocketInputBuffer, to issue a non block 
>> read, that would read data into the first buffer, to see if there 
>> even was any data. this would solve our non-blocking read issue. 
>> Basically the length would then have to be kept around so that when a 
>> read is issued, and there already is some data in the buffer, don't 
>> reissue it, and just return the length.
>
> If you do a read, it would be to call 
> connector.InputBuffer.realReadBytes, and I'm still not sure about it 
> (I think the servlet could be interested in an eventual exception, for 
> example). Doing a read at the lower level is not useful as the bytes 
> may not be actual data.
yes, but that's ok. the sequence would be this
a) available() == 1
b) InputStream.read() == 0
c) available() == 0
what this would mean, is that available()==1 means there is data fetched 
from the actual socket, may or may not translate into user data.
In the sequence above, that is such a case, available returned 1, cause 
there was data, read returned 0 cause it didn't translate into user 
data, and further attempts to available() showed that there were no more 
data to be fetched.

When new data comes in, available() (non blocking) again shows up as 1, 
InputStream.read() may or may not return data.

I personally, think this would be an extremely elegant way to do non 
blocking read, as this would also be useful for regular servlets.

>
>> 3. Still haven't come up with a good/clean idea for non block write, 
>> next week will open up much more time for this.
>>   For a while I was thinking of registering the connection for 
>> Poller.WRITE, to notify the servlet when a write is doable without 
>> blocking, however, this cause the same concurrency issues as the 
>> Poller.READ does, so I have put it on the back burner for now.
>
> Write polling is a bit difficult probably.
yes, lets defer it for a bit, its a concurrency nightmare.

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