tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Comet changes
Date Tue, 08 May 2007 22:38:26 GMT
Filip Hanik - Dev Lists wrote:
> Here are some changes.
> 1. The background thread should not have to call notifyWrite, since we 
> provide READ event, we can also provide
>   an automatic event is thrown when a write completes EventType=NOTIFY 
> EventSubType=WRITE_COMPLETE, as soon as the write does complete
>   One exception, if the write completes on the first write attempt, 
> canWrite returns true immediately after outputstream/writer.write(...)
>   It is easier to implement, as we don't have to keep track of if they 
> want to be notified or not.
>   So basically, outputstream.write() -> canWrite==true -> we finished 
> writing everything
>   and in the same fashion, outputstream.write() -> canWrite==false -> we 
> can expect a NOTIFY event
>   canWrite should measure the length of bbuf, that's the easiest way to 
> know if we can write or not

I agree, but I don't understand how you can know if you can write 
without a write polling. If there are no events on read, I have the 
impression writing could be suspended for an indefinite amount of time. 
So if it works, I am fine with this process.

> 3. Since a write can timeout, and event ERROR/TIMEOUT might happen 
> instead of NOTIFY/WRITE_COMPLETE.
>   This is one case where ERROR/TIMEOUT should close the socket, and that 
> is why I think it should always do it
>   regardless of have we do it now. Keeping a connection open after a 
> TIMEOUT is not good, cause it makes it so much harder to clean up
>   In a write timeout, we have data left in a buffer

I don't want to do any special funky tracking of writes in the APR 
connector, so I disagree with this (feel free to keep it in the NIO 
connector if you want to, I'm fine with that). It's also a gratuitous 
action which does not provide a real benefit.

> 4. Implementation detail, in TC 6 the buffers are sent in a separate 
> flush to the socket
>   Can we just merge this with the first servlet flush or automatic flush
>   This will simply send the response headers with the first data for the 
> response, hence be included in the
>   "non block" write logic without further workarounds for that.

I believe the number of writes should be kept as low as possible.

> 5. non block read
>   After thinking about it, and since we send "events" when data is 
> available on the socket
>   I don't think we should enable them.
>   The only time a non block read, would be in Comet connections that are 
> in:
>   a) the connection is non block mode &&
>   b) the connection is not registered for a OP_READ with the Poller
>   Because of the concurrency problems that can arise from non-block read 
> and the connection being registered for READ with the poller,
>   this feature is actually better if it is left implemented as it is today.
> 
> 6. READ event
>   However, there is a need to modify the read, currently the 
> CoyoteAdapter will end up in a blocking read if not enough data
>   has been fetched that is needed for the filter.
>   The filter should be able to back out, so that the connection gets 
> returned to the poller to retrieve more data
>   Bottom line is that Comet threads should never call inputstream.read() 
> unless it is a READ event
>   If we feel there is a need, we can make non block read available to 
> the servlet, although I see that lower priority than the write
>   stuff and the blocking CoyoteAdapter.read

I don't think you can have non blocking writes and blocking reads (at 
least I don't know how to do it with APR). I wanted to point out that 
non blocking reads and blocking reads were almost equivalent.

> 1 background thread

Ah, the "feel good" factor ;)

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