Menu
▾
▴
wrapper-user
|
From: Clement, N. <ncl...@qv...> - 2003-04-02 08:18:15
|
Leif,
Thanks for your quick reply! The application was trying to output about 9MB
worth of log data at the time (something we're obviously going to try and
reduce). I have installed the 3.0.1 version of wrapper and have not seen
the problem since. I will monitor it closely over the coming days and let
you know if the problem re-occurs.
My original question still stands - I'm uncomfortable with the idea of the
application being restarted automatically. I'd rather our support people
have to restart the application manually in the rare event of a JVM hang.
Would it be possible to disable pinging completely as an option for advanced
users? Just a suggestion of course.
Thanks very much for your prompt assistance!
Nathan
From: Leif Mortenson <leif@ta...>
Re: Disabling JVM ping
2003-04-01 04:22
Nathan,
Does your application output large amounts of output to the console?
There was bug
that would cause the native side of the Wrapper to spend too much time
processing
input from the JVM and forget about doing its other jobs. This was
causing timeouts
like you mentioned below. It actually had nothing to do with pinging
that is why
changing the ping timeout had no effect for you.
I fixed this in 3.0.1 that was just released a couple days ago.
Could you please give
that version a try and get back to me about whether or not it fixes your
problem.
Be sure to return any modified timeouts to their default values.
Also note that there were some changes with the scripts and config
file in the 3.0.0
release. You should no longer set the pid in the wrapper conf file. It
is now handled
from within the shell scripts. This was done to reduce the number of
things that a
user has to modify.
Cheers,
Leif
|
|
From: Clement, N. <ncl...@qv...> - 2003-04-03 00:21:48
Attachments:
console.zip
|
Here's the message again with the log trimmed more -----Original Message----- From: Clement, Nathan Sent: Thursday, 3 April 2003 10:13 To: 'wra...@li...' Subject: RE: Disabling JVM ping Leif, The new configurable Java side timeout sounds like a good idea. We haven't had any problems with the application in question overnight, which is obviously a good start. However, we have had a similar problem with another application in a customer's environment. This environment seems unique in some way, because we can't replicate the problem in any of our test environments. I have attached the log of the wrapper trying to start the JVM. The key lines I saw are as follows: Wrapper Process has not received any CPU time for 52 seconds. Extending timeouts. The Wrapper code did not ping the JVM for 40 seconds. Quit and let the wrapper resynch. The problem occurs continually on startup - the wrapper starts the JVM, then the application almost starts up, and finally quits because it has not been pinged for 30 seconds. The restarts occur repeatedly until the wrapper gives up. I don't know why the wrapper process is not getting any CPU for this long - the logging on startup is not what I'd call excessive (only about 60k per start-up). The interesting thing is that if the wrapper is run interactively (not as a service), the application starts fine and continues to work without problems. Since this is a customer's environment, any suggestions you can provide would be welcome. Thanks again, Nathan From: Leif Mortenson <leif@ta...> Re: RE: Disabling JVM ping 2003-04-02 02:08 Wow, you want to disable the feature that led me to create the Wrapper in the first place... Having just had problems with restarting I can understand your concern. But in general, the Wrapper is quite good about only restarting the JVM when it is really necessary. The ability to sleep well at night and put the old pager in the bottom drawer where it belongs should be viewed as a good thing :-) The wrapper.ping.timeout property controls how long the Wrapper will allow to pass without the JVM responding to a ping. The problem was inverted in your case. The Wrapper process was busy and failed to ping the JVM. The JVM side of the Wrapper has a feature that will cause it to exit and let the Wrapper restart it if it ever fails to be pinged for a long period of time. The thinking there was to avoid the JVM turning into a zombie process if the Wrapper process ever died abnormally. The fact that this Java side timeout is hard coded at 30 seconds was an oversight. It should have been the same as the ping timeout on the Wrapper side. A fix is now in CVS and will be in the 3.0.2 release. I don't want to do a release just for this as it is not a critical problem. Unless you really need this immediately for some reason, I'll wait until there are more things needing to be released. You can also do a build from CVS to get it sooner. Cheers, Leif |
|
From: Leif M. <le...@ta...> - 2003-04-03 02:58:30
|
Clement,
The messages about extending timeouts are being caused by either the
Wrapper or JVM process not receiving CPU for an extended period of time.
This can happen for a number of reasons including one or more applications
on the system consuming all the CPU. The messages about extending
timeouts are not a problem, they are merely telling you that that other
timeouts like the ping timeout are being extended.
The log that you sent contains lots of information about your
application,
but unfortunately, it doesn't tell me very much about what is going on with
the Wrapper. I know it is a pain as this is at a customer site, but
could you
set the following properties and then send me the resulting log file? Go
ahead and post the reply message to the list, but only send the log file
to me
off list, no reason to post the whole thing to the list as it is a bit
large.
Send me the full log file without any trimming. Include two failed startups
as a service and one as a console so I can compare them.
wrapper.logfile.format=LPTM
wrapper.logfile.loglevel=DEBUG
Cheers,
Leif
Clement, Nathan wrote:
>Leif,
>
>The new configurable Java side timeout sounds like a good idea. We haven't
>had any problems with the application in question overnight, which is
>obviously a good start.
>
>However, we have had a similar problem with another application in a
>customer's environment. This environment seems unique in some way, because
>we can't replicate the problem in any of our test environments. I have
>attached the log of the wrapper trying to start the JVM. The key lines I
>saw are as follows:
>
>Wrapper Process has not received any CPU time for 52 seconds. Extending
>timeouts.
>
>The Wrapper code did not ping the JVM for 40 seconds. Quit and let the
>wrapper resynch.
>
>The problem occurs continually on startup - the wrapper starts the JVM, then
>the application almost starts up, and finally quits because it has not been
>pinged for 30 seconds. The restarts occur repeatedly until the wrapper
>gives up. I don't know why the wrapper process is not getting any CPU for
>this long - the logging on startup is not what I'd call excessive (only
>about 60k per start-up).
>
>The interesting thing is that if the wrapper is run interactively (not as a
>service), the application starts fine and continues to work without
>problems.
>
>Since this is a customer's environment, any suggestions you can provide
>would be welcome.
>
>Thanks again,
>
>Nathan
>
>
|
|
From: Leif M. <le...@ta...> - 2003-04-02 10:08:33
|
Clement, Nathan wrote: >Thanks for your quick reply! The application was trying to output about 9MB >worth of log data at the time (something we're obviously going to try and >reduce). I have installed the 3.0.1 version of wrapper and have not seen >the problem since. I will monitor it closely over the coming days and let >you know if the problem re-occurs. > Good, it sounded like the same problem. This new version should not have any more problems with restarts related to large amounts of output. >My original question still stands - I'm uncomfortable with the idea of the >application being restarted automatically. I'd rather our support people >have to restart the application manually in the rare event of a JVM hang. >Would it be possible to disable pinging completely as an option for advanced >users? Just a suggestion of course. > Wow, you want to disable the feature that led me to create the Wrapper in the first place... Having just had problems with restarting I can understand your concern. But in general, the Wrapper is quite good about only restarting the JVM when it is really necessary. The ability to sleep well at night and put the old pager in the bottom drawer where it belongs should be viewed as a good thing :-) The wrapper.ping.timeout property controls how long the Wrapper will allow to pass without the JVM responding to a ping. The problem was inverted in your case. The Wrapper process was busy and failed to ping the JVM. The JVM side of the Wrapper has a feature that will cause it to exit and let the Wrapper restart it if it ever fails to be pinged for a long period of time. The thinking there was to avoid the JVM turning into a zombie process if the Wrapper process ever died abnormally. The fact that this Java side timeout is hard coded at 30 seconds was an oversight. It should have been the same as the ping timeout on the Wrapper side. A fix is now in CVS and will be in the 3.0.2 release. I don't want to do a release just for this as it is not a critical problem. Unless you really need this immediately for some reason, I'll wait until there are more things needing to be released. You can also do a build from CVS to get it sooner. Cheers, Leif |
