Yoav Shapira wrote:
Hi,

On 6/7/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
fail-fast the connection using an IOException (the servlet would
effectively only handle clients which are "fast enough" if using the
Comet API like in Tomcat 6.0, which avoids a lot of issues)

This is an interesting assumption, but I think it's valid for this type of API.

Yes, it's a bit an assumption. Since there's no "blocking or non blocking ?" question mark, it simplifies significantly the documentation of the API.

The main issue is how to handle a write which would block, and would most probably cause problems when doing async writes (as others pointed out - Filip, I think), so in that case, if the Servlet chooses not to handle it using isWriteable - which makes sense in many cases -, I think the exception throwing is fine.

The only situation where it could cause real problems is if the write is done inside another event (like in the common "reply later" pattern), and I think it would most likely work well enough due to the existence of buffers at the servlet layer. It's quite easy to add back blocking mode if needed, and tricks could be used rather than rely on direct configuration. For example, while I think adding code to detect what is called asynchronously for error checking purposes is useless, it could be possible to detect if the problematic write is sync or async, and adjust blocking mode accordingly at the connector level rather than throwing the exception.

The idea is to make the API simpler overall than what it is in 6.0 (despite the addition of 3 methods and 2 event types, I think it would be simpler to work with due to the sleep/callback methods which allow doing common things very easily), and avoid introducing heavier constructs and method calls.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to