mod_jk found in TC 3.3 and jakarta-tomcat-connector
handle correctly the Tomcat restart.
Could you test it ?
-
Henri Gomez ___[_]____
EMAIL : [EMAIL PROTECTED] (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-----Original Message-----
>From: Jason Koeninger [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 29, 2001 8:54 PM
>To: [EMAIL PROTECTED]
>Subject: Re: mod_jk load-balancing and errors
>
>
>What version are you using? The mod_jk I'm using that was
>compiled from the 3.3m3 distribution seems to be handling
>dropped connections better, but my system isn't load balanced.
>
>As far as option (a) below, I think ajp12 does that (makes a
>new connection each time) which is what makes it slower
>than ajp13.
>
>Best Regards,
>
>Jason Koeninger
>J&J Computer Consulting
>http://www.jjcc.com
>
>
>On Fri, 29 Jun 2001 09:15:42 -0700, Patrick Tiquet wrote:
>
>>I'm attempting to setup Apache/mod_jk to load-balance through
>a hardware
>>load-balancer. So far it works, I get nice, even, balancing
>of requests
>>between Tomcat servers. All is fine until I shutdown one of the Tomcat
>>servers...
>>When I shutdown one of the Tomcat servers I'm load-balancing
>to, I get a few
>>errors, and then everything is fine. I assume that this is
>because mod_jk
>>keeps a pool of open connections to the Tomcat servers, and
>then when it
>>tries to send a request down one of the connections to the
>absent Tomcat
>>server, it returns an error, and then closes that connection.
>>What I am trying to do is eliminate these errors I get when a
>Tomcat server
>>goes away. I tried placing a hardware load-balancer between Apache and
>>Tomcat, but then discovered that I ran into the same problem
>thanks to the
>>pool of persistent connections.
>>It would be great if mod_jk would either a) Make a new
>connection to Tomcat
>>for each request so that a hardware load-balancer can be
>placed between the
>>two and will only direct requests to the Tomcat server(s) that are
>>functioning... or b) mod_jk smart enough to not send a
>request down a dead
>>connection.
>>Any thoughts or suggestions?
>>
>
>
