In this case, operations can use the init.d script to restart the server.

Our plan was to implement automatically restart as we knew more about the patterns of failure that would require restart. Automatically restart is, of course, a pretty high-risk function. As Jetty was extremely stable in our environment, we never found the need to implement automatic restart.

When deploying jetty like this, do you have another process on the same server that monitors and make sure that it runs? And that is capable of starting the process if it’s down, like Commons Daemons?

I’m not an operation expert, but I would like to understand what’s common practice. ;)

As for configurations I have become an avid user of Constretto, where the configuration is embedded in the jar – living up the idea that “the environment is part of the design”..

The short answer is: Yes, I’ve used Jetty in production, and I recommend others to do it if possible. You’re exactly right about the deployment being an OS process and not within an application server.

Contrary to popular belief (or at least vendor claims), operations people that I talk to love this. I don’t know any operations people who feel an app server is within their comfort zone.

I’ve used a system with shell scripts that will start a Java main-class (or “java -jar”) and capture the PID to a file if run with the argument “start”. If started with the argument “stop”, the script will issue “kill `cat pidfile`”.

I’ve also used a separate Servlet Context to control the server. Connecting to http://localhost:/shutdown from localhost with a secret HTTP parameter will cause Jetty to stop. The main-class of my server will try to do this before starting its own listener. I haven’t used this scheme in production yet.

My plan is that “cd /opt/application/production; java -jar application.war restart” will restart the server. This will make for good init.d-support.

On my previous production deployment with Jetty, we used Apache HTTPD as a reverse proxy in front of the server (mod_proxy). I was pretty happy with this approach. If given free reign, I probably would prefer to use Nginx in the same way.

I read a property file (named application.property) from the CWD and add it to System.getProperties() at startup. This file contains necessary configuration like http port (and database connection properties).

Hope this helps. Keep up the good questions!

However, there are a few hurdles and missing pieces, that I really want to find out about.

I am curious, do you deploy the application like this in production? I would think that it would be smart to have some monitoring process that checks if the process is running and restarts if it’s not. Do you use Common Deamons for that? In that case, there are some “integration issues”, because they would have to share the pid-file. Let’s say the Common Daemons is monitoring the process and we do a new deploy like described in your post, then the app will get a new process id and Daemons will try to start a new one… trouble.

It would have been nice to have had a framework that would support /etc/init.d/start-stop-script, process monitoring and fast “hot”-deployment as you described in this post. ;)

I guess something like the Rails guys have; Capistrano.

This would be different from normal java containers like Tomcat, because the control will be on the OS-process-level and not within Java.

I wish this existed.

Another issue I find with this approach, versus deploying wars to a Tomcat, is that each jetty instance would need to have their own http and JMX port configured uniquely, and hence would raise the need for a httpd front server and some more configuration. What are your thoughts on this?

Your questions are very insightful, and I’m happy to see that you’re exploring the code. :-)

WarExtractor “reaches around” and tries to find what one-jar jar file was used to start it. It then unpacks the WAR-file from this Jar file and puts it in a temporary location on the file system in order to execute it. It’s a … hack. :-)
ShutdownControl and StatusHandler are both used to control an already running server. If I start the server in the background and then leave the console, I can use ShutdownController to shut it down from another console. Similarly, I can use StatusHandler/checkStatus from another console to decide whether I need to start a new server instance or not
ShutdownControl is also useful when I run WebServer under the debugger in Eclipse or IDEA. I can then just start the debugger again, and it will kill any already running session.
I use the WebServer in embedded-container-web for development testing (start it in an Eclipse/IDEA debugger session). ServerControl is the one that’s started when you execute “java -jar …” after deploying to a test or production environment.
The block with “server.checkStatus” is to avoid running a second jetty on the same computer (on the same port). If you run “java -Dserver.checkStatus -jar ….” this is the behavior you get.

Thanks for the questions. Please do ask more. :-)

So I’m starting with Java (only having programmed for the web in Django), and I wanted to avoid the complexity of application servers and all that J2EE stuff for now.
So your post was a great find, the demo worked perfectly, but there are several things I don’t get there, such as:

- What does the WarExtractor do? Is it being used when I run java -jar embedded-..container-one.jar ?

- I kinda understood (and tested) ShutdownControl, but I don’t understand why do you would want it. What’s the difference between this and a Ctrl-c in the screen session, or killing the process? BTW, when I shutdown (via cookie method) it said it could not stop a thread – did that happen to you? No idea which thread is this.

- In the function StatusHandler.java/checkStatus, you use your own HTTP service to check the status. Why would you do this instead of just calling the method?

- Are the files under embedded-container-web only for testing? Would you be running the main() inside WebServer.java or the one inside ServerControl.java for development?

- What is the purpose of the block which starts with “if (getBooleanProperty(“server.checkStatus”, false))” on ServerControl.java? To avoid running a second jetty in the same computer?

I know it might seem silly, but I don’t want to start my project using code that I don’t understand, of course…

Thanks in advance,
Hugo

Anyway, I would better create a simple test case that shows how much memory overhead this solution has.

http://commons.apache.org/daemon/
http://wrapper.tanukisoftware.com/doc/english/download.jsp
http://yajsw.sourceforge.net/
http://forge.ow2.org/projects/javaservice

I would recommend to start trying from Apache Commons Daemon. It used for Apache Tomcat for example.