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