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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
