I like to write a little server application being controlled by a little console app (start, pause, stop, etc). For the server spring should be used (part of it already exist). So what I do to start the server is something like this:
start a server thread and exit main method
and then, in the thread:
load application context from xml
start some worker threads connecting to beans doing stuff
Now I want the server to be stopped by another command. How can I connect to the already running context and shut it down?
Thanks for your help,
Alexander
The classical way to manage running Java code is through JMX.
Spring lets you export beans as MBeans.
And for accessing JMX via the command line, look at the answers to this recent question:
Calling JMX MBean method from a shell script
You could create a pid file, when the server starts, it should log the pid to a file, server.pid. When you do a stop, you can read the process and kill it. Or even simpler, have a ever running thread in your main class which keeps looking for a file in some folder. As soon as the file becomes available or gets modified, it will stop the server.
Related
I've got a Java8 application running on RHEL 6.10. This application registers a shutdown handler via the usual method:
Thread shutdownThread = new Thread(()=>{
Logger.info("Got shutdown signal");
// Do cleanup
});
Runtime.getRuntime().addShutdownHook(shutdownThread);
This application is kicked off by a Jenkins build (with the BUILD_ID env var set to dontkillme). The application initializes successfully, but then after ~30 seconds the shutdown hook is called and the application terminates. I'm trying to figure out who is shutting me down and why. I've monitored top and it doesn't appear that memory is an issue while it's running, so I don't think the OOM killer is the culprit. I've also looked at /var/log/dmesg and /var/log/messages and don't see anything relevant there either. I don't think Jenkins would be killing me, both since I set BUILD_ID and also because the application dies while the "parent" Jenkins job is still running.
What other methods / tools can I use to see what's happening? Note that my environment is very locked down, so it would be difficult to download and run something from the internet, hopefully there's something in a standard RHEL6 install I could use.
The answer turned out to be unique to the application in question. The application uses the zookeeper-3.5.5 library to connect to a Zookeeper instance. This client library has a runtime dependency on the zookeeper-jute jar, and when that jar was not present in the executing directory, this issue presented itself.
You're probably wondering why the application silently shut itself down and didn't throw a ClassNotFoundException which would have helped me debug this. Great question! I have no idea.
This is my first time asking a question on Stack Overflow. I recently configured an Ubuntu 16.04 virtual private server to host a web application. I run ngnix on a Tomcat server that reads and writes to a MySQL database. The application runs fine except for the fact that Tomcat restarts itself once in a while which results in a 500 error that stems from a "broken-pipe" when anyone tries to login (i.e. make a connection to the database).
I will post an image of the 500 next time it happens. I went into my vps and looked at my Tomcat restart message. This is what I see: Tomcat status message.
I also did a little diving into the Tomcat logs and this is a log file that corresponds with that restart time: Tomcat log file
I did some research to try and solve this myself, but with no success. I believe that the exit=143 is the process being terminated by another program or the system itself. I also have done some moving of the mysql-connector-java.jar. I read that it should be located in the Tomcat/lib directory and not in the WEB-INF of the web application. Perhaps I need to configure other settings.
Any help or any direction would be much appreciated. I've fought this issue for a week with having learned much, but accomplished little.
Thanks
Look at the timeline. It starts at 19:49:23.766 in the Tomcat log with this message:
A valid shutdown command was received via the shutdown port. Stopping the Server instance.
Exit code 143 is a result of that shutdown and doesn't indicate anything.
The question you need answered is: Who send that shutdown command, and why?
On a side note: The earlier messages indicates that Tomcat lost connection to the database, and that you didn't configure a validation query. You should always configure that, since database connections in the connection pool will go stale, and that needs to be detected.
Theory: Do you have some monitoring service running that tests your application being up? Does that monitoring detect a timed-out database connection, classify that as a hung webapp and auto-restart Tomcat?
While I don't think I am able to see to the core of the problem you have with your overall setup given the small excerpt of your log files, one thing strikes the eye. In the Tomcat log, there is the line
A valid shutdown command was received via the shutdown port. Stopping the server instance.
This explains why the server was restarted. Someone (some external process, a malicious attacker, script, or whatever. Could be anything depending on the setup of your server) sent a shutdown command to Tomcat's shutdown port (8005 by default) which made the Tomcat shut down.
Refer to OWASP's recommendations for securing a Tomcat server instance for fixing this possible security whole.
Regarding the ostensible Hibernate problems you have, I don't get enough information from your logs to make a useful statement. But you can leave the MySQL jar in Tomcat/lib, since this is not the root cause of your problem.
if we are to have an RMI server application which runs permanently via autosys and then shuts down for a few hours over night, how to we send the shutdown message if the application was started from the command line.
for example, we start the jar using java -jar server.jar and now the application is running. if it contained a applicationClose() method how could we call it - we could parse the message from the client but of course this is undesirable?
It is perfectly acceptable to make a closedown request method available, that returns OK and then calls System.exit().
You might want to protect it with some sort of required credentials before it can be called, but other than that there is no reason why you can't.
The other option is for the process to have another TCP port open with your own protocol for shutting down, or to have a JMX extension installed to remotely shut down the service.
It might sound a bit too naive, but I always had a tough time to debug a java class during server startup. Here is the scenario:
The java application is hosted on a tomcat server.
Suppose there is a class which is invoked while the tomcat server starts up.
As soon as I stop the tomcat instance for a restart, the eclipse debug stops and I can start the debug only once the application is up and running.
Now how do I debug this class on eclipse?
Thanks for you help in advance.
You need to pass the "wait for debugger to connect" flag to tomcat. So the startup will wait until you have connected and thus you won't miss the breakpoint.
Take for example those java options to make tomcat listen for a debugger:
-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8797,server=y,suspend=y
The wait for a debugger connection flag is the suspend=y entry in the above line.
Debugging of classes during startup should work without problems. For example, suppose you implement a ServletContextListener class. The belonging contextInitialized method is called during Tomcat startup (or to be more precise: while your app gets deployed).
You can set breakpoints in this class. At that point, Tomcat is already started completely and there shouldn't be any problems with debugging.
I want to be able to monitor a process's existence continuously and restart it if it had crashed or killed for any reason using JMX. Stopping and starting a process is not a probelm as the agent executes a script for it. I can monitor process's existence by implementing heartbeats between the agent and the monitored process but I am looking for something using JMX itself, if something exists?
You can expose the component as a JMX managed resource.
Try to do the heartbeat.
If you get instanceNotFound from the managed bean server then it has crashed.