Costin Manolache wrote:
In the sandbox version: - sleep() and setTimeout(int) -> why not sleep(int millis) ? I think it's confusing to have both and the interactions between them, in particular setTimeout is marked optional ? It makes sense to have setTimeout() as a general timeout.
setTimeout() is not optional (the javadoc is out of date, sorry), there was an agreement on that earlier. Timeout sets the connection timeout, which is most likely useful even if there are events. It's quite possible sleep could use a timeout argument (I think calling setTimeout is more or less mandatory when using sleep, and OTOH calling setTimout is not as important otherwise).
- not sure I understand the use case for isReadable()/isWriteable() - when will this be called ? My understanding was that when the connection is readable, a callback will be generated with EventType == READ. Also it's very confusing to mix the 'blocking' in the isReadable()/isWriteable() - it would be much cleaner to say that the connection is always non-blocking, and add a method to switch to blocking mode ( then use the regular servlet methods maybe ). Using the ComentEvent for both is IMHO dangerous.
Although the read event indicates there's data to read, isReadable indicates if it is possible to continue reading.
isWriteable indicates if the last write operation managed to write more than 0 bytes. If the last write wrote 0, then isWriteable will return false, so the servlet knows it should stop writing on this connection for now (since it cannot accept any output at the moment). Later on, the servlet will receive a write event, and can resume writing.
It is possible to add a blockingMode flag, but I've looked into it a bit, and found out it is not really needed: - If doing asynchronous writes using a background thread, non blocking helps (if somehow a connection blocks, no other connection will get any data until the write completes or times out). I don't see how blocking mode could be desired in this case, and the servlet should always be using isWriteable. - If doing synchronous writes inside some event (either a read or callback event, most likely), then both blocking and non blocking mode make sense. Some servlets may prefer to use blocking mode although it could be holding a thread for a while (for example if the idea is only to delay the response), and some others could choose to be more scalable. Since it is possible to detect if the write is done inside a Tomcat thread, and since a servlet which wishes to handle incomplete writes would be using isWriteable, it is possible to know when we're in the situation where the servlet would prefer blocking. In that case, the algorithm in the write method of the connector would be: check if the last write returned 0, set blocking mode, flush leftover bytes and send the additional bytes which are being written, set non blocking mode. It's a trick (of course, it is possible to do the same thing for read), and the main drawback is that there are extra operations, but they would occur only if needed.
- will sleep() still allow callbacks ( and if not - what will happen with them )? What's going to happen with callbacks if callback() is not called ?
Yes, sleep is meant mostly to handle the reply-later design easily. The servlet calls sleep(), and is supposed to call callback() (asnychronously, most likely) as a result of something. The connection will then wake and the servlet will get a callback event. If callback is not called, the connection will timeout and the servlet will get its timeout event (according to the connector timeout or the one that has been configured for the connection).
In general ( both versions): - it would be great to move it from o.a.catalina to org.apache.comet
It's a possibility. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
