Resin Watchdog
Today I had a Resin user ask about the Resin watchdog and how it works. We’ve got some documentation, but I thought I’d show an example here in case you’ve never had a chance to try it out or were confused. I’ll show the actual command line input and output that you’ll see. After that, I’ll also talk about a feature we’re considering adding watchdog which we’d like feedback on.
The watchdog is a simple Java process that we introduced in the 3.1 branch to get away from the annoyances of the shell scripts of 3.0 or earlier. Writing it in Java makes the start process of Resin more portable as well. The other purpose of the watchdog is to restart Resin if the process dies. If you’re using Resin 3.1 or 4.0, you’re already using the watchdog, whether you realize it or not!
In the case of a single Resin server with id “a”, this is how we start the server with the watchdog and what processes are running after startup:
% java -jar lib/resin.jar -server a start Resin/4.0.0 launching watchdog at 127.0.0.1:6600 Resin/4.0.0 started -server 'a' for watchdog at 127.0.0.1:6600 % jps 2356 Jps 2178 Resin 2153 WatchdogManager
If I kill the Resin instance, the watchdog will restart it. If I kill the watchdog, both Resin and the watchdog will go down. The right way to stop the processes is to use “stop” instead of “start” above though. Notice that the first line in the output after starting the Resin server is a notification that the watchdog is starting. If there’s no watchdog, the command line starts one. If there is one, the command line asks it to start the new server.
For example if we have two servers on the same machine, they’ll use the same watchdog by default:
% java -jar lib/resin.jar -server a start Resin/4.0.0 launching watchdog at 127.0.0.1:6600 Resin/4.0.0 started -server 'a' for watchdog at 127.0.0.1:6600 % java -jar lib/resin.jar -server b start Resin/4.0.0 started -server 'b' for watchdog at 127.0.0.1:6600 % jps 8502 Jps 8439 Resin 8299 WatchdogManager 8324 Resin
In this case, killing the watchdog kills both Resins as well. If you “stop” both of the servers, the watchdog will go away in that case as well.
One other quick note about something that tripped up a user on resin-interest earlier this week: Only Resin checks for changes to the resin.conf or resin.xml. If you change something in the configuration that affects the watchdog, you need to restart it manually yourself. This is especially important if you change the users and/or passwords in the
Letting the watchdog off the leash?
Currently, when the last Resin instance is “stopped” properly, the watchdog goes away. We’re considering adding the ability to let the watchdog stay around as a permanent daemon and do remote start and stop of Resin instances via JMX and /resin-admin (and/or Maven, etc.) In fact, you could start the watchdog first without starting any Resins until later. The tradeoff is that the Watchdog code becomes more complicated. At first, we wanted the watchdog to be as simple as possible, so adding this functionality would introduce more complexity.
What do you think? Is the added functionality worth it?
