I was wondering if there is a \'smooth way\' of redeploying a Java WAR to a production server (no cluster, no OSGi)?
All I can come up with is stop server, update file,
Some application servers do support redeployment without interruption of service. This is at least true for WebLogic, see Using Production Redeployment to Update Applications. Note that this is not hot deploy (and I would NEVER use hot deploy with production servers).
Without application server support, I'm afraid you won't be able to do real "smooth" redeployments. If you want to minimize downtime, one approach is to deploy the new application in parallel (on the same server or another one) and to change the routing rules when done. But clients will loose their session.
Usually, mv old.war new.war
and let the AS take it from there, although with very busy 24/7 services, I imagine this wouldn't be an option.
Usually it's possible to optimize start-up time. Our web application starts with Jetty in 5-7 seconds. Other Java web servers are worse, because they start very slow.
Also, as I'm aware (not I did it), the front-end web server (such as apache, we use lighttpd) could be configured to hold request some period of time (up to 30 seconds on ours) while the Jetty is not ready. So, we just easily restart the Jetty while deploying, and users just have several seconds delay in worst case, which usually just looks like an Internet connection glitch.
You might have a look at JRebel, though I wouldn't use it in production. In production we do basically the same, though our boss keeps on dreaming of hot redeploys. Unfortunately they are supported mostly on paper - in most complex applications something always goes wrong with hot redeploys. The same is even truer for incremental hot redeploys...
First, hot-deploy doesn't always work. We spent so much time to make sure every new module is loaded and decided it's not worth the trouble. So what you are doing may sound bad but it's the most reliable way to deploy a new WAR.
Our current approach is to use a switch with load-balancer in front of all servers. We run at least 2 instances of the application servers. When we shutdown one server for maintenance, the traffic automatically goes to the other one.
Some of the switches are really inexpensive. If you don't have enough load to justify a new box and your 2 instances can run on the same box.
In some circumstances, the switches can actually save money. For example, we have a SSL page that used to use 6 boxes and now it runs fine on 2 boxes with SSL acceleration in the switch.
As ZZ Coder has already mentioned load balancer is a good solution especially for big deployments. For my own project I use reverse http proxy functionality of nginx web server. It redirects all http packets from a specified web context (seen from the Internet) to a server inside my network. Configuration is really easy:
location /best-app-ever/ {
proxy_pass host-address:8080/some-app-1.1
root /home/www/some-app-1.1
}
Switching version should be smooth as well. Assuming that you have already deployed new version of application just change nginx configuration file and apply changes:
location /best-app-ever/ {
proxy_pass host-address:8080/some-app-1.2
root /home/www/some-app-1.2
}
sudo nginx -t
sudo service nginx restart
Be warned that in case your web application is stateful and/or contains some running or scheduled processes, the deployment and undeployment might not be as smooth.