> > We have an application running as a webapp which requires legacy > systems and network resources which are not fault-tolerant. Luckily > these resources are stateless. So we have replicated these > resources so > that one is available per tomcat instance. When we attempt > to use one > of these resources from within the webapp and it fails, we need a way > to try the next pair (tomcat & legacy) in the group. This > will allow > us to provide a balanced & fault-tolerant service with a webapp > interface. Since the tomcat instance is responding and functioning, > the reply_timeout was not met so apache webserver considered the > request a success. Providing a application error from tomcat > (maybe a > 503 or 401 instead of 500) seemed like the "rightest" way to do it. > > I see a few other options: > > 1. Put a layer on top of apache that tests the response and > makes a new > request. This doesn't buy us anything and circumvents the use of jk > 2. (some how/maigcally) Send an out of process message from > tomcat back > to apache that the resource is down. > 3. Modify AJP to handle this error (this may already have a mechanism > that I missed) > > Does any one have any other suggestions for ensuring reliability when > there is a 3rd party piece of hardware/software which your webapp > relies on that has no fault-tolerance of its own? >
I may be totally missing the point here, but isn't this something that could be handled in a servlet filter. If you have an availability problem, set a flag in the response header that the filter can check for and take appropriate action? Regards Roger __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
