Hi,

On Thu, Nov 19, 2009 at 12:50:44AM +0100, Rainer Jung wrote:
> 
> On 18.11.2009 17:01, conrad-tomcat.users.2...@tivano.de wrote:
> > 
> > As you can see, 24552 (=3 * 8184) bytes are received almost immediately,
> 
> 8184 looks like the body size of one full AJP packet (protocol used by
> mod_jk and Tomcat).

yep, that's what I thought, too. It looks like the last, partially filled
AJP packet from the Tomcat response is not making it through the SSL
layer, somehow. Or whatever signals "end of response" to the SSL layer.

> > while the rest is only transferred after 5 seconds. Leaving "-0" away
> > from the curl command line, the complete result is received immediately.
> > Requesting the same page via http instead of https, the complete result
> > is received immediately. The 5-second-delay can be seen using wget
> > instead of curl, too, so this is probably not a client problem.
> >
> > So far, the problem has only been seen on the production system.
> > Due to the load conditions, it is infeasible to run mod_jk with significant
> > logging output.
> 
> To bad.
> 
> > mod_jk configuration is straightforward, timeouts are not defined (i. e.
> > we use default values).
> 
> That's not so nice but also likely not the cause of the problem. Can you
> run a network sniff (Wireshark et.al.) between Apache and Tomcat?

No, that's infeasible due to the high traffic volume.

> the
> AJP protocol is pretty clear text, so you could verify, whether the 5
> seconds are caused by Apache (in case the full content has beend
> delivered by Tomcat well before), or the reason is Tomcat or your webapp
> (in case the last response content packet really comes with the delay).

The webapp behaviour (for this page) depends neither on the HTTP protocol
version nor on the presence of SSL. So I'm certain that the webapp delivers
the complete response immediately.

Bye,
        Peter
-- 
Peter Conrad
Tivano Software GmbH
Bahnhofstr. 18
63263 Neu-Isenburg
Tel: 06102 / 8099070
Fax: 06102 / 8099071
HRB 11680, AG Offenbach/Main
Geschäftsführer: Martin Apel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to