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]