tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastiaan van Erk <>
Subject Re: Comet: problem with request.getParameter() in Comet POST requests
Date Wed, 02 May 2007 10:47:36 GMT
> 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 

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 

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).


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message