By Byronnevins-Oracle on Apr 26, 2009
GlassFish V3 is now sporting a brand new capability: Remote Restart.
This feature is particularly handy for environments where the server machine is secured and difficult to get to. With the right credentials you can now restart the server from anywhere in the world -- as well as from the same machine.
It is very easy to use. As of today there are two ways to call the restart-domain command with the third method coming online soon
(1) Use a URL in a browser:
(2) Use asadmin like so:
asadmin --host yourhost restart-domain
(3) Coming soon: Admin Console GUI support for the command
The asadmin command, restart-domain, is what I like to call a "hybrid" command. It is both a local and a remote command. The local portion of the command's job is to block until it verifies that the server has completed its restart and is online and ready to go. The remote portion does the actual restarting.
There are 3 main flavors of starting non-embedded V3. Restart-domain works with all three:
- Starting the server with the launcher (i.e. asadmin start-domain). Restarting will stop the running server and once the JVM process is guaranteed to have exited the server will restart. There are no special "watchdog" processes involved. The server itself does the work itself in what I like to call "reincarnation". This is easy to see by running jps during the restart. You will see the process id change. You can also watch the server log as the server restarts.
- Starting the server with the launcher in verbose mode (i.e. asadmin start-domain --verbose). The key point here is that we have to preserve the console that asadmin owns here. So we do the restart a little differently. Since the asadmin process is also running on the server machine, we ask the already running asadmin process to restart the server for us. asadmin does all the heavy lifting here.
- Starting the server in implanted mode (e.g. java -jar glassfish.jar). A new jvm will be started with exactly the same commandline arguments. Note that if the server owns the console -- i.e. is running "in the foreground" and mirroring log messages -- the new server will lose control of the console. We can not absolutely guarantee a clean shutdown without literally closing down the JVM itself. Once that is done the console is out of reach.