Results concerning setting reuse to JK_FALSE:
I tested closing the connections in ajp_done after each request. It
shows the following behaviour:
- TCP packet dump shows a correct Fin-Ack... sequence, i.e. a regular
TCP connection shutdown.
- mod_jk logs opening of a new connection for each request
- Tomcat 5.5.17 logs
DEBUG (ChannelSocket.java:675) - server has been restarted or reset t
his connection
at the end of each connection. The line comes from:
org/apache/jk/common/ChannelSocket.java
...
663 /** Process a single ajp connection.
664 */
665 void processConnection(MsgContext ep) {
666 try {
667 MsgAjp recv=new MsgAjp();
668 while( running ) {
669 if(paused) { // Drop the connection on pause
670 break;
671 }
672 int status= this.receive( recv, ep );
673 if( status <= 0 ) {
674 if( status==-3)
675 log.debug( "server has been restarted or
reset this connection" );
676 else
677 log.warn("Closing ajp connection " +
status );
678 break;
679 }
680 ep.setLong( MsgContext.TIMER_RECEIVED,
System.currentTimeMillis());
681
...
This block hasn't changed in the last two years.
The "-3" comes from read() in the same Class:
621 // connection just closed by remote.
622 if (got <= 0) {
623 // This happens periodically, as apache restarts
624 // periodically.
625 // It should be more gracefull ! - another
feature for Ajp14
626 // log.warn( "server has closed the current
connection (-1)" );
627 return -3;
628 }
- API docs for getInputStream() in Socket say:
==================
Under abnormal conditions the underlying connection may be broken by the
remote host or the network software (for example a connection reset in
the case of TCP connections). When a broken connection is detected by
the network software the following applies to the returned input stream:
...
If there are no bytes buffered on the socket, or all buffered bytes have
been consumed by read, then all subsequent calls to read will throw an
IOException.
==================
So it looks like this situation should be the same on all platforms.
- Even under "ab -n 10000 -c 20" and several JVM Thread-Dumps, I can not
find any Threads in bad stacks.
So I think the Tomcat problem with recent code is a non-issue. If anyone
has different experience please correct me.
Regards,
Rainer
Rainer Jung schrieb:
> I checked the whole thread, but I found no technical description of the
> problem observed. So apart from discussing the uses and stability of any
> do-not-reuse implementation, I would be interested in understanding the
> real problem, which started the discussion.
>
> - What is known about the TCP behaviour of the firewall, i.e. what
> exactly has been observed with respect to TCP packets?
> - What are the platforms and versions of the used components on the
> Apache and the Tomcat side?
>
> W.r.t. the problem of shutting down a socket from the apache side and
> wasting tomcat threads, I never experienced a problem with that on *nix
> systems. I'll check again carefully, but I would be interested in any
> concrete information on which platforms and how such a problem can be
> reproduced.
>
> Regards,
>
> Rainer
>
> Jim Jagielski schrieb:
>> I and other have run into issues where the socket
>> between Apache and Tomcat (due to a in-between firewall)
>> isn't closed as it should be... I'm digging further into
>> this as far as why the timeout isn't being honored, but
>> it got me thinking that a "no reuse" option might be
>> nice. Basically, it prevents reuse from ever being set
>> to TRUE...
>>
>> PS: Also to be done with mod_proxy_ajp as well, but that's
>> a different list :)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
