8

I'm using a custom signal handler to catch TERM, ABRT and INT signals in a custom java daemon. I have this handler in the code so that I can send TERM signals to it and gracefully shutdown the program via the kill command. The signal handler works right now, but when I compile the code I'm receiving the following warning (many times over):

warning: sun.misc.SignalHandler is Sun proprietary API and may be removed in a future release

while using these classes:

import sun.misc.SignalHandler;
import sun.misc.Signal;

Is there a better way to send signals to a running JVM to initiate a shutdown of the main thread? I don't like having my code tied to this API when it could be removed in the future.

This code works on Solaris and HPUX today using 1.5.0_22 JVM. Any help or suggestions would be much appreciated. I used this document, from IBM, to develop the signal handler:

http://www.ibm.com/developerworks/java/library/i-signalhandling/

jmq
  • 10,110
  • 16
  • 58
  • 71
  • 1
    As far as I know there's no public API for signal handling (probably because it's too OS-specific), so you'll have to put up with this warning. – biziclop Feb 16 '11 at 23:39

2 Answers2

17

First of all, understand that this is just a standard warning for sun.misc package. They're letting you know that the API you're using is not a standard Java API. It doesn't mean that they're actively planning to remove this API in the future. http://java.sun.com/products/jdk/faq/faq-sun-packages.html

As far as your question, it's not quite clear to me why the default way java process handles kill signals is not sufficient for you: How to stop java process gracefully?. If you need to add additional logic, you can add a shutdown hook.

Still, If you're looking for other ways to let your java process know it's time to exit, you can have it listen on a socket, or stdin, or a named pipe...

You might also want to look into JVMTI

Community
  • 1
  • 1
ykaganovich
  • 14,736
  • 8
  • 59
  • 96
  • Your "How to stop a java process gracefully" was very helpful. I did a search and I'm not sure how I missed that one. I looked over my script that performs the kill and it is doing "kill -9". I think I'm sending the wrong signal, according to that link, and hard killing the app (which is why I had to trap the signal during the shutdown for graceful exit). I'm going to try a different signal, and the shutdown hooks, and see if that is a better solution. – jmq Feb 17 '11 at 00:49
  • 3
    This ultimately worked and I was able to remove those two classes from the project. Your suggestion was helpful, thank you. – jmq Feb 17 '11 at 22:11
3

You could do this via JMX. JMX is a standard set of apis that can be used to monitor and manage java applications.

Here are some links to get you started :

http://onjava.com/pub/a/onjava/2004/09/29/tigerjmx.html

http://www.ibm.com/developerworks/java/library/j-jtp09196/index.html?ca=drs

The main idea is this :

a) You will have a boolean variable, say isShutDownTrigerred. You will have a thread that will run a infinite loop, sleep for 2s, and keeps checking this variable value. When the value is true, you will execute code that will shutdown the application.

b) Then you write a mxbean (check the links above). This mxbean will be used to change the "isShutDownTrigerred" value to true. You can use a tool like jconsole /jManage to see and modify the mxbeans of a java application. As soon as the "isShutDownTriggered" is set to true, the above thread is going to know it and will execute the shutdown of the application

Zenil
  • 1,491
  • 3
  • 12
  • 21