i have a storm topology class which starts a kafka spout and bolts. This class is main class. I am trying to clean exit storm topology, so i have created a shutdown hook in side that topology main method.
//Shutdown hook
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
System.out.println("Inside shutdown hook.");
Utils.sleep(1000000);
cluster.killTopology("netra-fault-management");
cluster.shutdown();
logger.info("Shutting down Topology.");
}
});
Here is my shutdown hook which is in main method of tolpology class. I run it from command prompt and when i do ctrl+c it is expected to run this shutdown hook but it just closes and no hook code is called . Do any buddy have idea about that how to run it on ctrl+c (SIGINT).
With Runtime#addShutdownHook, it is possible.
The problem should be caused by Utils.sleep(1000000);. You should not "sleep" the shutdown thread as The Java Virtual Machine(and other applications) doesn't allow it. A shutdown hook is designed to be called when the application is about to be closed, to save important stuffs or unload resources, etc. The Java Virtual Machine will terminate after few seconds, even the thread isn't executed completely.
In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly. This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run.
From JavaDoc for Runtime class. Sometimes the shutdown hook will not be called. Good luck!
See Nathan Marz commenting on a similar question years ago, I presume the behaviour has not changed:
https://groups.google.com/forum/#!topic/storm-user/A4-uFS6px2Y
Storm shuts down worker processes with SIGKILL, the JVM will not execute the shutdown hook under those circumstances (like it would for SIGINT).
As far as I understood from this and this, they've implemented a change allowing the shutdown hook to fire, but the hooks code is limited to one second, so OK for some scenarios. Hovewer, I didn't check personally as it's not enough for my case which is buffer upload. But there is alternative approach for me that I'm going to implement.
Related
This doc states that the JVM doesn't stop the JAVA process if there are non-daemon threads alive in the process.
When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class). The Java Virtual Machine continues to execute threads until either of the following occurs:
The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.
I've tested this with starting a standalone Thread, an ExecutorService and a NioEventLoopGroup and it works as stated above.
But, for this sample Netty Echo Server, it states the following:
75 // Wait until the server socket is closed.
76 f.channel().closeFuture().sync();
If I remove this line the code terminates even though there are non-daemon threads alive in the process.
Can someone please explain why?
I'm interested in different approaches to gracefully shutting down a Java command line program. Sending a kill signal is not an option.
I can think of a few different approaches.
Open a port and wait for a connection. When one is made, gracefully shutdown.
Watch for a file to be created, then shutdown.
Read some input from the terminal, such as "execute shutdown".
The third one is not ideal, since there is often program output pumped to the screen. The first one takes too much effort (I'm lazy). Do most programmers use the second option? If not, what else is possible/elegant/simple?
you can try something like this:
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() { /*
my shutdown code here
*/ }
});
edit:
the shutdown hook will not perform the shutting down of the app. instead, it gives the developer a way to perform any clean-up that he/she wishes at shutdown.
from the JavaDoc for Runtime (a good read if you are planning to use this method):
A shutdown hook is simply an initialized but unstarted thread. When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently. When all the hooks have finished it will then run all uninvoked finalizers if finalization-on-exit has been enabled. Finally, the virtual machine will halt. ...
you could try to use Runtime.getRuntime().addShutdownHook() that should satisfy your requisite. In this way you can register an hook to do cleanups, in order to perfom a gracefull shutdown.
EDIT
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)
public void addShutdownHook(Thread hook)
Registers a new virtual-machine shutdown hook.
The Java virtual machine shuts down in response to two kinds of events:
The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit) method is invoked, or
The virtual machine is terminated in response to a user interrupt, such as typing ^C, or a system-wide event, such as user logoff or system shutdown.
The benefit of the second option - checking for a file - over the first - listening on a port - is that you have some possibility of security.
You can set the permissions on the directory where the file is created so that only appropriate users can close the program. If you listen on a port any user can connect to it.
If you wanted to go with the socket version, it is very simple to implement. Here's the code:
ServerSocket server = new ServerSocket(8080);
System.out.println("Socket listening!");
server.accept();
System.out.println("Connection received!");
You could easily embed this code in a separate thread that you start with your program, and then have it modify global state to initiate shutdown.
The first two option is simple to implement. You could also use some JMX stuff (I don't know much about that). Tomcat uses the first approach and I applied 1 and 2 in two of my projects.
Consider having a JMX component. Then you can attach with JConsole either locally or over the network, and communicate with your component. Then the component can shut down the program properly.
With Java 6 u 10 or later, you can do the same with JVisualVM.
I would suggest to use the shutdown hook. It will allow your program do be controlled using standard OS tools. It also does not need any additional access to external resources (disk, ports, whatever).
I created a webapplication that needs to do some cleanup on shutdown. This cleanup will take about a minute and its completely OK for it to do so.
When I deploy my webapp onto Tomcat 8 and then stop it, my ContextListener gets called and the cleanup begins. But it seems like Tomcat stops my thread the hard way and it won't complete anymore. At least on Tomcat 6 that wasn't an issue.
An ideas how to configure Tomcat 8 to stop from misbehaving?
Partial Answer:
I found out it has something to do with a performance optimization I did. I used startStopThreads="2" to start my applications in parallel, which works out well, but on shutdown this also seems to kill my threads.
If you have a task which is to be performed on shutdown, I would add this as shutdown hook. Most likely Tomcat 8 is called System.exit() which is a normal thing to do and this kills all user threads but start shutdown hooks.
A better solution is to never leave the system in a state where you really need this. i.e. you cannot assume an application will die gracefully.
if you are waiting for client to disconnect, I suggest you add a shutting down phase. During this phase you refuse new connections, move connections to another server or attempt to gracefully tell existing ones you are going away. After a short period or time out, you then shut down.
I have a main java program which should launch other java programs in an own process using Runtime.exec(), e.g.
Runtime.exec("java -jar myapp.jar");
Is there a possibility to communicate with this new process, e.g. sending request, chaing fields...?
How can I shutdown this new created process? I think I get an handler back and thus can kill the process. But is there a nicer way?
If I kill the process, will the shutdownhook still be executed before the process is killed?
Runtime.getRuntime().addShutdownHook
Is there a possibility to communicate with this new process, e.g. sending request, chaing fields...?
You can communicate with the process through the Process object returned by Runtime.exec. Just use Process.getInputStream/.getOutputStream.
If you want to invoke methods on the other Java process you could look into RMI ("Remote method invocation"). Another option is of course sockets. See this related answer.
There's no straight forward platform independent way of changing fields of the other Java process.
If I kill the process, will the shutdownhook still be executed before the process is killed?
Depends on how you kill it, but typically, yes, the shutdown hooks will be executed.
console java application. Someone kill java.exe process by Task Manager. How can I write to logs some information at this moment before application is terminated?
Thread.currentThread().setUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
public void uncaughtException(Thread t, Throwable e) { ..... }
});
OR
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() { ..... }
});
don't execute in such situation
This is not possible. Shutdown hooks will only be executed in an orderly shutdown:
In rare circumstances the virtual
machine may abort, that is, stop
running without shutting down cleanly.
This occurs when the virtual machine
is terminated externally, for example
with the SIGKILL signal on Unix or the
TerminateProcess call on Microsoft
Windows.
You can send another signal that will trigger an orderly shutdown like SIGINT. Killing a application should be the last resort after the application did not respond.
some practical solutions have already been suggested, but another is to ping-pong a "last status" message between 2 applications that monitor each other. When one dies, the other one writes the last received message to a log file. Users can't kill both processes quickly enough with Task Manager.
Some sort of solution is to write something to a log file all the time. This way you'll see whatever was the "last breath" of the Java program.
you might try to start java.exe via a small naive (e.g. c++) application using a CreateProcess (in windows ) this application will then continue running monitoring the java process handle. if the java process is gone it can log it.
Give your users an orderly way to shut down the system, and tell them to stop using Task Manager to do so.