tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Proposed new CometEvent.notify method
Date Thu, 03 May 2007 15:11:12 GMT
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.

> 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).

> 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.

> 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.

Rémy


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


Mime
View raw message