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.
When I worked on ajp13++ (ajp14) protocol, I added a more secure auth mecanism at connection time.
Since there is a bidirectionnal communication, jk could detect that even if the connection is open, the remote didn't respond and so fall back to the next in cluster configuration.
But on allready established connections, the problem persist.
Or we should add a PING/PONG before sending any request to tomcat.
It could be done as optional but I work on it only if many users make such requirements
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
