|
From: Leif M. <le...@ta...> - 2006-11-10 23:17:38
|
Robey,
Unfortunately, I can't simply remove this signal handling. There
have been cases on
Solaris where the Java process was receiving TERM signals from an
unknown source
that was leading to a shutdown. The fix was to add the ignore signals
features to the
wrapper.
Under normal operation, the wrapper and its JVM are shutdown using
signals
sent to the wrapper process. But unfortunately this is not always the
only target
of signals.
I will look into modifying this code so it does some actual
synchronization.
I didn't that code would have any problems even when not synchronized, but
I guess it does.
If you could give me some more information as to how to reproduce
this, it would
be helpful.
Cheers,
Leif
Robey Pointer wrote:
> 3rd patch of 4. This one is a little rough. Basically, under high
> load, catching signals inside JNI causes the JVM to crash, at least on
> Linux. Crashing the JVM is really bad, and basically a
> non-recoverable error for any java code.
>
> Since signals are caught by the wrapper process and passed to the JVM
> across a control channel, there is no reason for JNI code to try to
> handle signals anyway, so we just uncommented this code. This may
> need more discussion: What is this code meant to be used for?
>
> In general, my experience has been that the JVM tends to use signals
> for its own purposes, so trying to catch signals in the JVM is bad
> medicine. This is especially true for things like HUP, USR1, and USR2.
>
> robey
|