|
From: Wrapper U. <wr...@co...> - 2004-05-18 15:09:16
|
As I understand it now, the wrapper can only trigger on an output string. Is there any way (or near-future plans) to trigger on something other than output. For example, if the program throws an Exception, or trigger on the exit code of the application? In my specific case, I'm having an application "service1" (which I'm under the assumption can't be changed to display different output) tries to connect to a (naming) server "service0". Note that service0 will also be launched by a wrapper. So, basically, service0 should be started before service1. But I'm starting them with the init.d services in Linux, so that can't be guaranteed. The way service1 works is that, upon starting up, it will try to connect to service0. If service0 is not running, service1 will retry to connect a number of times before giving up and exiting with exit code 1. When it can't connect to service0, service1 prints the following: ---------------------------------------------------------- jvm 1 | [ Retrying to connect to 127.0.0.1:1234 ] ...number of times... jvm 1 | [ Retrying to connect to 127.0.0.1:1234 ] jvm 1 | [ Retrying to connect to 127.0.0.1:1234 ] wrapper | <-- Wrapper Stopped ---------------------------------------------------------- So as you see, there's really no unique string it prints out that I can trigger on after it failed n times. I found it exits with exit code 1 by running the wrapper with logging set to debug. Anyway, in theory, at the same time, a different wrapper instance could (in my case should) be off starting service0, so I'd like service1's wrapper to restart service1 with the hope that service0 will eventually be up to connect to. Allowing the wrapper to trigger on service1's exit code would help. As a workaround (kluge?) , I could just trigger on the "Retrying to connect" string, but that would restart after each failed connect, as opposed to after the program exits in failure. Another (totally separate) solution would be (and I'm just brainstorming here) putting some dependencies on different wrapper applications. Something like writing a totally separate script that somehow checks if service0 is running (service0 status) before it launches service1... Any ideas? Thanks, Aiman |