Hi Henk, I'll try to find the reason. Would it be easy for you to repeat the test with a very raw client? If the URL is easy you could e.g. telnet to the APACHE port and simply write
GET /myurlRETURN RETURN I'm asking for that, because the client write error sounds a little strange to me, and I want to make sure, that it's not the client, which produces the problem concerning the missing header. Regards, Rainer Henk Fictorie schrieb: > Ok, I did the snooping and analyzing. > > What happens is at follows: > - mod_jk sends request > - tomcat responds within a fraction of a second > - tomcat ends with sending an 'end-response' message with reuseport set to > TRUE > - exacat 5 minutes (300 seconds) later mod_jk report a client write error > (jk_ajp_common.c (1410)) > - mod_jk closes the tcp-connection (FIN) > - and writes a entry to the request logfile. > - apache also writes an entry to the access logging > > I think that somehow mod_jk does not recognize the 'end-response' message > and closes the connection after a timeout of 300 seconds. The 300 timeout is > not a setting in the mod_jk configuration, neither is some value send bij > the browser. In our apache 2 configuration we have set the Timeout > parameter to 300 seconds, so this it the most likely trigger to cause this > behaviour. > > So my question are: > - will setting "JkOptions +FlushPackets" cricumvent this behaviour. > - any ideas about the real cause of this problem. > > Noticable: > In our response neither a 'Content-Length' or a 'Transfer-Encoding: chunked' > is send, could this be delaying sending the response to the browser? > > regards Henk Fictorie > > > > Rainer Jung-3 wrote: >> Henk Fictorie wrote: >>> I think I will snoop the traffic with Tomcat during one hour or so (appr. >>> 1 >>> Gig of data, on a different filesystem). Using editcap to divide the >>> capturefile in reasonable sized parts. Examining the logfile will reveal >>> at >>> what moment and from which ip-adres the slow requests are coming. I can >>> then use ethereal to examine the traffic and timing for that particular >>> request. >> Sounds like a good plan. I'm very interested in your findings. Keep your >> original packet capture files around, not only the ascii versions. If >> possible, snoop inclusing the whole packet contents, not only the first >> 1200 Bytes or so. >> >> > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
