Re: [Wrapper-user] JVM exited in response to signal UNKNOWN (127)

[Leif M. <le...@ta...>]

Amresh,
What platform is this running on?   I had a problem at a customer
several years ago on Solaris where the Wrapper would sometimes
receive TERM signals from someplace.  The solution was to add a
feature to ignore all system signals.   That works for all signals
except for the SIGKILL.  Which it appears you are receiving.

How easy is this for you to reproduce?  If you set
wrapper.debug=true then the Wrapper will add log data about
which process sent the signals.  That might be useful to track
down where the stray signals are coming from.

In the case of my old customer, it was another user application
which was using old PIDs to try clean up its own process instances.

To enable the ignore singals feature simple edit the wrapper's
shell script uncomment the following line:
#IGNORE_SIGNALS=true

As you upgraded the Wrapper, make sure that you are also
upgrading the shell script.

Let me know how this works out.
Cheers,
Leif
 

Amresh Deshmukh wrote:
> We have been using wrapper for last few years.
>
> We were using version 3.1.2 of the wrapper and have recently upgraded to the latest version 3.2.3.
>
> The reason for upgrade was the error:
>
> "Critical error: wait for JVM process failed (No child processes)" 
>
> Which as I found was fixed in version 3.2.0.
>
> After the upgrade we have seen occurence of the following error in our log files. 
>
> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response to signal UNKNOWN (127).
> ERROR | wrapper | 2007/09/27 15:32:51 | JVM exited unexpectedly.
> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response to signal SIGKILL (9).
> ERROR | wrapper | 2007/09/27 15:32:51 | Unable to start a JVM
> STATUS | wrapper | 2007/09/27 15:32:51 | <-- Wrapper Stopped
>
> We have put in a fix today for the "Unable to start a JVM" using the suggestion in one of the posts.
>
> wrapper.on_exit.default=RESTART
> wrapper.on_exit.0=SHUTDOWN
>
> We have also increased the restart delay to 30 seconds.
>
> wrapper.restart.delay=30
>
> The problem now is the fact that the JVM restart results in loss of cached data which impacts performance at the time of batch processing.
>
>
> We are running on 64 bit Linux OS with 32 bit jdk1.5.0_12 JVM (32 bit limitation due a third party library)
> OS details: 
> Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
> Linux 2.4.21-32.0.1.ELsmp #1 SMP EDT x86_64
>
> It would be very helpful to know under what circumstances we could get an error like this. We are in last week of UAT due to go live next week any resolution/workaround for this would be highly appreciated.
>
>
> Amresh
>