Menu
▾
▴
Re: [Wrapper-user] restart tuning
|
From: <da...@sm...> - 2006-04-06 12:58:43
|
This is a difficult one to gauge from the Wrappers perspective, and is entirely dependant upon the application it is wrapping. The way that the wrapper is set up is to deal with applications that "can" get themselves into a spot of bother, not really "always will". It I am guessing is designed to cater for those strange errors that sneak into an application that you don't see normally, that hang the app, but the next time you run mysteriously go away. One thing, why don't you set the set the startup time like Leif says to be either 0 or a very large time (like 5 years), and constantly call signalStarting(...), and then when the application has done everything you wanted it to do successfully, call signalStarted(). That way if your app crashes whilst starting up, it should get counted against the max failed invocations. What appears to be happening, is the Wrapper has considered your app started, and thinks "Oh, it had a spot of bother during the regular running, lets restart it to keep the service it provides alive as much as possible". Hope this helps Anat, 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 > |
