Hi,
Wouldn't every application which isn't as dumb as the chat example
(which does not care about the content it reads but simply passes it
back to it's clients) need to implement it's own mechanism to check
whether there is enough input available to start parsing a chunk of
data?
Either that, or you can parse the information "on demand", as it comes in.
Is it really the intention of Comet that each application must care
about these things?
The input part of Comet allows you to process input as it comes in. This
necessarily makes matters more complex than a blocking read.
Is there no way to enable a Servlet to do a blocking read if it
recognizes that a client has sent a chunk of data?
It would not block for a long time in that situation (only until the
missing tcp packets of the actual chunk have arrived). This would allow
a much more convenient handling of input for most applications.
Matthias
What you seem to want is more in line with the "asynchronous servlet"
(request, wait, response), which Filip and Remy pointed out is not the
quite the same as Tomcat's Comet. Ideally, both models would be possible
through single unified API, but this is currently not yet the case.
The reason I was wondering about the getParameters() method is because
it is a part of the Servlet API (specifically, the request object), and
it SEEMS to work in Comet, but there is no guarantee that it will.
Either this could be considered to be a bug (a fix being that
getParameter() blocks until all parameter data is in), or it should be
documented somewhere that getParameter() should not be used in the
CometProcessor.
As for blocking reads in your servlet, I don't think there is anything
which prevents you from doing multiple blocking reads from the request
input stream in a READ event. The description of the READ event is as
follows:
EventType.READ: This indicates that input data is available, and that
one read can be made without blocking.
It does not say you are not allowed to do additional reads (with the
risk of blocking). Note that I have not tried this yet, and it might not
work. It would be useful to have a thorough description of the API which
documents these things (as well as other issues such as synchronization,
lifetime/scope of the event object, etc), with a clear seperation
between API (things one can depend on), and implementation details
(things which happen to work some way due to the current implementation
but are subject to change without notice).
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
