Rémy Maucherat wrote:
On 4/26/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
Note that there really IS a bug here:
request.getInputStream().available() returns 0 in the BEGIN event, so I
cannot test if the data is already available there. However, the API
seems cleaner to me anyway if you only allow reads within the READ
event, as the documentation suggests it should be.
I am fully aware of all of what you have written, and maybe
available() will become more accurate in the future.
However, I think you are able to deal with it for now, since you know
if there's going to be data sent along with the request header or not.
Rémy
I find this suggestion a terrible workaround and the use of the word
"maybe" a bit disturbing.
First of all, I do not know when the client is going to send the data.
If it sends it immediately then sure, a read in the BEGIN event will be
fine, otherwise it will block. The whole point of using Comet is to not
have your http threads block. Second of all, how do I know that the
client is going to send any data at all? Third of all, assuming the
client does NOT send data, the CometProcessor will be blocked in the
event() method trying to read data. Depending on the synchronization and
how Tomcat works internally, this is a recipe for deadlock. Will the
event method ever be called concurrently from within Tomcat? If not,
I'll never get an ERROR event, causing the thread to block forever.
I generally don't like to depend on client behavior for the proper
functioning of the server.
It seems to me that this really is a bug, and the proper fix still seems
a call to the READ event. It makes more sense than reading in the BEGIN
event.
If you want I can file a bug report in bugzilla.
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]
