If a servlet (probably incorrectly) closes the writer/outputstream of a response, and then attempts to read from the request, the AJP connector sends GET BODY CHUNK to the mod_jk worker. This then starts a series of very confusing communication between the worker and tomcat. The worker doesn't read it until it makes its next request. After making its next request, it reads it, and then sends a response with 0 length. At the same time, Tomcat responds to the request made by the worker with another GET BODY CHUNK, which the worker also responds with a message of 0 length. Then the really weird thing happens, Tomcat replays the first request made by that worker. At this point, based on what I'm looking at with tcpdump, I get too confused to work out exactly what is happening.
Thanks for the report. Which version of mod_jk and which config are you using?
The version of mod_jk is 1.2.28 on CentOS 5.4. If you are unable to reproduce this issue, let me know and I'll do more investigations to reproduce it on my side, I'll see if I can reproduce it on later versions of Tomcat and I'll attach tcpdump logs etc. I haven't done that yet because the only logs and environment that I have handy are a production environment, and the logs contain sensitive information, but I'm hoping my description so far is adequate.
I've also hit this issue in tomcat 6.0.26 and 7.0.4. This has been using an in-house version of the AJP client (webserver-side). Our symptoms were the same, and we had been working around by disabling connection sharing across requests. Following James' advice, I've removed the possibility for a servlet-side read from the request after the response has been closed. This has resolved the issue of us.
Fixed in 7.0.x and will be included in 7.0.9. An attempt to read from the request once the response has been will trigger an exception. I'll also propose back-ports for 6.0.x and 5.5.x
Fixed in 6.0.x and will be included in 6.0.33 onwards.
This has been fixed in 5.5.x and will be included in 5.5.34 onwards.