Christophe Pierret wrote:
I only had to port the patches for http://issues.apache.org/bugzilla/show_bug.cgi?id=40960 and http://issues.apache.org/bugzilla/show_bug.cgi?id=37869
These two patches have been merged in HEAD.
Feedback on the Comet API: - There may be some ways to improve the documentation of the API: from what I saw (I got caught by this one :-), it seems that one need to call CometEvent.close() before throwing an exception in READ events or the event keeps coming back forever. I could not find a reference to this behaviour in documentation.
Throw an exception like what ? If an exception is thrown by something in the event method, it should close the connection with an error without further problems (CoyoteAdapter.event will return false to the connector's event method, which does return a code asking for closing the socket - and more importantly, doesn't put it back in the poller). CometEvent.close() doesn't do much, so I don't understand how it can cause a different behavior.
- Is there a rationale for receiving READ events when request.getInputStream().available()==0 ?
There's a reason: the actual read will be done on the socket when you read on the Java input stream, so it's normal to have available == 0. The event guarantees that the blocking read will not block. Filip suggested having the read done before calling event, but I thought it added complexity.
Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
