|
From: <da...@sm...> - 2006-04-06 13:02:26
|
On the other hand, I can see also where you would like the Wrapper to go. For Server applications, where you want the maximum availability and reliability, you want the wrapper to ALWAYS restart the app when it gets into trouble. For your app and others that match the requirement, you want less availability and reliability, and you want the wrapper to restart the app up to X number of times when the app has actually started. If it still is misbehaving, then just don't try to run the app anymore. Like I said in my previous email, Wrapper is designed more to deal with the first kind, but I do see usefulness in the second type. What do you think Leif? David Hayes Quoting Anat Halpern <an...@en...>: > Yeah, I can set a very long time, no problem, and also using 0 as > indefinite time should work, but this looks more like a workaround > (which will work fine for now). > I would have expected the wrapper to count the number of abnormal > terminations, regardless of the run time before this crash. BTW, this > is what I understood from the docs. If for example, an application > analyzes an input file and crashes on a specific input, (let's say > near the end of the file), then it will crash continuously. > > Cheers, > Anat > > Leif Mortenson wrote: >> Anat, >> Currently, all restarts are viewed the same way by the Wrapper. >> The thinking is that >> something that happens shortly after startup is most likely a >> configuration or permanent >> problem, where as something that happens after the application has >> been running for a >> while is temporary and can be resolved by restarting. >> The wrapper.successful_invocation_time property defines this line. >> >> As you need to call restart once on startup, the max failed >> invocations needs to be >> 2. Then you will need to define a >> wrapper.successful_invocation_time to prevent the >> count from being reset. The example below sets this time to 5 years. >> >> wrapper.max_failed_invocations=2 >> wrapper.successful_invocation_time=157788000 >> >> I can modify the wrapper.successful_invocation_time property so >> that a value of >> 0 will be interpreted as infinite time. Would this make sense? >> >> How exactly would you like the Wrapper to behave? >> >> Cheers, >> Leif >> >> >> Anat Halpern wrote: >>> Thanks for your help, Leif. >>> >>> The first option is problematic, as the crash is not time-dependent. >>> As for the option of using disable.restarts, I have to be able to >>> call WrapperManager.restart explicitly, at least once, (this is my >>> workaround for the GUI problem we discussed before - I restart the >>> application after I'm done with the GUI). >>> So to make this clear, the problem is: explicit restarts are >>> required, but I'd still like to limit number of restarts on account >>> of failure in the run. >>> >>> According to the description of max_failed_invocations: " Maximum >>> number of times that the Wrapper will attempt to restart the JVM if >>> each attempted invocation exits abnormally or...". In my case, the >>> JVM exists abnormally each time, but still the time factor is >>> considered. Is it possible to disregard the time and consider only >>> the success/failure of the run? If not, I think the documentation >>> should be changed a bit. >>> >>> Thanks a lot, >>> Anat >>> >>> Leif Mortenson wrote: >>>> Anat, >>>> If you use the wrapper.max_failed_invocations=1 property, you >>>> will also need to set the wrapper.successful_invocation_time property to >>>> a large value as you said. >>>> http://wrapper.tanukisoftware.org/doc/english/prop-max-failed-invocations.html http://wrapper.tanukisoftware.org/doc/english/prop-successful-invocation-time.html Good news is that as of 3.2.0, there is a better >>>> way: >>>> http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html >>>> The only difference from your request is that all restarts are >>>> treated the >>>> same way. This is true with the above properties as well. >>>> >>>> Cheers, >>>> Leif >>>> >>>> Anat Halpern wrote: >>>>> Hi all, >>>>> I'd like to disable all restarts except for explicit calls to >>>>> WrapperManager - is this possible? >>>>> >>>>> I've also tried to use the wrapper.max_failed_invocations, and it >>>>> did not work as I expected it to - the application kept running >>>>> for a while before crashing, so it was considered a successful >>>>> invocation. Is there any way of making the wrapper ignore the >>>>> successful_invocation_time property (except setting it to a >>>>> really large number)? >>>>> >>>>> The problem I'm trying to deal with is that the application runs, >>>>> and then, depending on the input, crashes. The wrapper handled >>>>> this situation by restarting the application over and over, >>>>> despite the wrapper.max_failed_invocations=2. >>>>> Any suggestions? >>>>> >>>>> Many thanks, >>>>> Anat >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting language >> that extends applications into web and mobile media. Attend the live webcast >> and join the prime developer group breaking into this new coding territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Wrapper-user mailing list >> Wra...@li... >> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> >> +++++++++++++++++++++++++++++++++++++++++++ >> This Mail Was Scanned By Mail-seCure System >> at the Tel-Aviv University CC. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |