Hi,
I found the cause of the missing READ event, and seems to me that it is
not too difficult to fix.
The problem is as follows. When Tomcat receives a request, the
Http11NioProcessor reads the headers. It does this by filling its
internal buffer using a read call on the socket. However, if there is
already more data available than just the headers, e.g., some request
body data, this is also read into the internal buffer. If the total data
is less than the size of the internal buffer, this means that there is
no more data available on the real socket channel, and after finishing
the BEGIN event there will not be another READ event until new data
arrives (and it may never arrive) on the socket channel to wake up the
Poller.
An easy way to reproduce this consistently is to have a client do a
request with a few bytes of data in the request body and placing a
breakpoint on line 839 of Http11NioProcessor so that all client data
arrives before Tomcat starts processing the headers.
An way to fix this is to check if there is request data remaining after
the parsing of the headers and if so, calling the event method of the
processor with a READ event directly after having called the BEGIN event.
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.
Regards,
Sebastiaan
Sebastiaan van Erk wrote:
Rémy Maucherat wrote:
On 4/26/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
The http://tomcat.apache.org/tomcat-6.0-doc/aio.html documentation
clear
states that I am not allowed to read from the input stream outside of
the READ event; thus I'm not allowed to read in the BEGIN event. So the
behavior I expect would be that I immediately get a READ event after
the
BEGIN event since there is data available.
I figure this is a bug?
The API is designed mostly for biderectional transfer. If somehow you
don't want to do that, then there's a lot less value in it (a thread
isn't that expensive, if all you want is wait a little bit before
generating a response).
If there's data available in the begin event (if the requests you use
send a request body), you should read it and if this "bug" is fixed,
it won't make a difference for you.
Rémy
I'm sorry but I don't understand your answer.
First of all, I use bidirectional communication: the client says A and
the server says B, the client says C, etc.. However, since the server
does not get a READ event for the initial A, the server just sits
there and does not respond at all. It needs a READ event to be able to
read from the input stream.
Secondly, I'm trying to understand the API. Either it IS or it IS NOT
allowed to read from the input stream in the BEGIN event. If I rely on
a certain behavior while reading in the BEGIN event now, it might very
well break in the future because I might be relying on the side effect
of an implementation detail. The answer seems to be to me a simple yes
or no; the documentation implies no.
Finally, I expect to get a READ event if there is data available, or
so the API seems to suggest. Then it seems to me that it is a bug if I
don't. To be helpful I am reporting it, so that if it is indeed a bug,
it may be fixed and the entire Tomcat community can profit from the
bug fix. Even a simple acknowledgement that it is a bug without a fix
is fine too, then I will look into the source myself and see if I can
locate the problem and suggest a patch/fix.
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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
