David Rees a écrit :

I posted this to tomcat-users last week, but didn't get a reply...  I'm
hoping to get some feedback from the connectors developers on this issue I
occasionally run into...

I've got a setup where I've got two load balanced Tomcats running off of
Apache and mod_jk.

I've got a problem where one of the Tomcats will occasionally hang, but
not die.  This means that it will accept new connections, but will not
actually process anything.  This renders all clients using the hung Tomcat
completely stuck as they are not switched over to the other Tomcat.

mod_jk seems to assume that if it can connect to Tomcat, it must be ready
to respond to requests.

Yes, if jk can connect to tomcat it assume it could handle the requests.


It seems that some sort of connection test (with a short socket timeout)
would be appropriate to validate that the connection is actually
responding.  While this would increase the latency of each request a bit,
it would improve the reliability.  Is there any provision in the AJP13
protocol to allow for testing of connections before sending a request over
it?

Nope since you don't have to just test at protocol level but also on higher level, for instance check the full chain, up to servlet handling.


It's easy to simulate this behavior by sending a STOP signal to Tomcat.

I've also attached a log from mod_jk showing the problem.  I marked the
point at which processing in mod_jk stopped until I sent a CONT signal to
tomcat.

Does mod_jk2 have this same problem?  Is there any interest in fixing
this? Does anyone have a workaround for this issue?

Well, if you have a hung tomcat, you're probably allready in serious trouble.


Anyway, if we add stuff like time-out in ajp request, you could be stuck with long running servlets. Also jk read request in a blocking mode for performance and adding timeout here is not an option.




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to