#66 JVM Process has not received any CPU time

[Anonymous]

I have successfully deployed the wrapper windows
service on 6 different computers and all have worked
well except for one.

The system in question runs Veritas which is a Java
based program for system backup. During the early
morning hours it performs the CPU and IO intensive
operation of creating a backup archive and then
verifying its contents. During the verification portion,
the following message appears in the Wrapper log
dozens of times:

INFO | jvm 1 | 2004/06/03 04:53:09 | JVM Process
has not received any CPU time for 156 seconds.
Extending timeouts.

And this is followed by the Wrapper exiting with:

ERROR | wrapper | 2004/06/03 05:00:12 | JVM appears
hung: Timed out waiting for signal from JVM.
ERROR | wrapper | 2004/06/03 05:00:12 | Java Virtual
Machine did not exit on request, terminated
STATUS | wrapper | 2004/06/03 05:00:19 | Launching
a JVM...
ERROR | wrapper | 2004/06/03 05:00:50 | Startup
failed: Timed out waiting for signal from JVM.
ERROR | wrapper | 2004/06/03 05:00:50 | Java Virtual
Machine did not exit on request, terminated

I have already tried setting the thread priority to the
max with:

Thread.currentThread().setPriority
(Thread.MAX_PRIORITY);

Also, I tried upping the timeout/exit values with:

wrapper.ping.timeout=180
wrapper.jvm_exit.timeout=60

Any suggestions about how I could combat Veritas
would be much appreciated.

I used integration method #3, wrote my own class that
implements the WrapperListener interface.

Wrapper version 3.0.5

Thanks,

David

david.limbach@workscape.com

[Nobody/Anonymous]

Wrapper config file

[Leif Mortenson]

Logged In: YES
user_id=228081

David,
Setting the thread priority inside of Java will not help.
If you really want to up the priority that Java is running
under then I would suggest using the
wrapper.ntservice.process_priority property.
http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-process-priority.html

Be careful doing so however, as it is easy to get into a
situation where you can't stop the wrapper if the JVM starts
eating 100% CPU.

A better option is to up the timeouts. The one that was
leading to the restart is wrapper.ping.timeout. I don't
know how long things are heavily loaded. Try a value of 300
(5 minutes). If the JVM does get restarted as above, then
you will need to also up the wrapper.startup.timeout to make
sure that the JVM has enough time to start up.

I have been working on improving this by implementing a new
tick based timer in 3.1.0. There were a few bugs with it
that release for some users. But I am planning a 3.1.1
release soon which has them fixed. The normal timer worked
fine in 3.1.0 so the problems were only for users trying out
the experimental timer.

Post back whether or not you are still having problems and
I'll try and get things working for you.

Cheers,
Leif

[Nobody/Anonymous]

Logged In: NO

Leif,

Thanks, that helped. The Veritas process runs for a few
hours and ties up the JVM for a large portion of that time.
The config changes you suggested did not stop the timeout
waiting for the JVM, but did fix the restart so that it would
not fail.

Thanks!

-David

[Leif Mortenson]

Logged In: YES
user_id=228081

David,
If the JVM is not being restarted then the startup timeout
is probably not an issue for you. But I know the reason
why the startup is probably not working. The following
change was made in the 3.1.0 release to fix a 3.0.5 bug:

* Fix a problem where the first ping timeout after the JVM
was started was
still hard coded at 30 seconds. This was causing a
combination of large
values of wrapper.ping.interval and wrapper.ping.timeout
to fail.

Unfortunately 3.1.0 introduced another bug which may affect you:

* Fix a problem introduced in 3.1.0 where the JVM would not
be restarted
correctly if it quit after a ping timeout to let the
Wrapper resynch and
restart it.

You have not seen this exact timeout, so it may not be an
issue. But under your extremely high loads, it seems
possible that you could. If the ping timeout was large
enough, it would not be an issue. You can try 3.1.0 if you
wish, but you should definitely upgrade to 3.1.1 when it is
released.

Cheers,
Leif

[Leif Mortenson]

Logged In: YES
user_id=228081

David,
3.1.1 was released today, so closing this off.

Cheers,
Leif