Hi Henk, do you have a simple app to reproduce the problem? Rainer Jung schrieb: > 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]
--------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
