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