Remy Maucherat wrote:
Remy Maucherat wrote:
Hi,
To more conveniently support some use cases, a new notify method
could be added to the event. This would do an action callback and
call a new method in the Poller class would add the socket to a
structure like the socket add list. The comet poller thread will then
check if there are sockets in that list, and call an event (as for
the event type, it could be a regular timeout - it's very similar -
or a new type which will behave the same as timeout - which would be
significantly harder since modifications will have to be made to
accommodate the new event type).
I know how to make this fairly easily with the APR connector, and I'm
not so sure about the NIO one (most likely it's very similar,
however). The main thing which is annoying to implement is if the
fact that there will not be any other concurrent event occurring has
to be enforced and there are multiple pollers (I think the socket has
to be removed "just in case" from each poller, which is quite annoying).
Along with it, I think a semi dynamic option should be added to not
use read polling (which does funky stuff in certain cases, since when
using pipelining, there's data available but the data may actually not
belong to this request), but still check timeout. I think per
connection timeout should also be supported by APR. Having these in
addition to notify() would allow all possible usage scenarios without
running into funny corner cases.
Just to understand it right event.notify() will call back into the
endpoint (through an actionhook) and this issues a
XXXEndpoint.process(socket) so that they the comet servlet has a worker
thread to piggy back on? (sort of simulate a read event), except the
event type will be NOTIFY, or the sub type will be NOTIFY.
That sounds good to me, since there are use cases that are very hard to
do if it is done asynchronously through an external thread.
Basically, to create an "async servlet" the code would simply look like this
a) make sure it is not registered for READ event
b) call event.close()
c) call event.notify() - yields a END or NOTIFY event
this would recycle the connection/req/resp, and voila, we have async
servlet, AJAX style.
Let me know if I'm on the wrong path here
So in terms of code could we
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.
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.
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.
thoughts on these suggestions? more to come from this corner soon,
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
