Hot Deploy a Java EAR to Minimize or Eliminate Downtime of an Application on a Server?

Question

I have heard that this is what JavaRebel does but is there any other good way to deploy a new version of an EAR while allowing users to remain active on the previous version? We use JBoss for the application server...

Answer 1

It's not what JavaRebel does. JavaRebel (according to description) hot-replaces the classes in memory. It's not acceptable in the case of existing connections to the system, since the updated classes may break the client's logic.

Once a company I was working for had a similar problem, and it was solved this way:

• a smart router was used as a load-balancer
• the new version was deployed to 50% of the nodes of the (new) cluster
• new connections were delivered strictly to these updated nodes, old ones were balanced between old nodes
• old nodes were took off-line (one-by-one, to keep number of clients per node within limits)
• at the same time, new version was deployed to off-line "old" nodes and they were brought up as new nodes
• due to EJB clustering, the sessions and beans were picked up by other old nodes
• eventually (in a few hours), only one old node left, having a single instance of old version and all clients using old version were connected to it
• when the last old client got disconnected, that node was too brought down

Now, I'm not a networking guy, and cannot give you many details (like what was the router hardware and such). My understanding this can be set up pretty easy, except, if I remember right, we had to setup an additional Weblogic domain to deploy new versions of the application (otherwise it would be conflicting with the old one on JNDI names).

Hope that helps.

PS Ichorus provided a comment saying that the app is deployed on clients' servers. So the router trick may be not feasible. Now, I see only one viable solution right now ( it's 21:52 now, I may overlook things :) ) --

• Develop new version with "versioned" JNDI names; eg if Customer bean was under ejb/Customer in version 1, in version 2 it would be under ejb/Customer2
• Have a business facade in the application with a stable basic interface (Factory-style) which, when asked for Customer bean, tries to find the highest-versioned JNDI name (not on every call, of course, can cache for a hour or so). That facade could (and should) be deployed as a separate application -- and never or very rarely updated
• Now every new client would get access to the latest application deployed, and the applications won't conflict.

This approach takes a careful planning and testing, but should work IMHO.

I recently modified a few applications in a similar way to let them coexist in the same domain (before they used the same JNDI name for different data sources).

Answer 2

As I understand WebLogic has a feature called parallel deployment to eliminate downtime during EAR version upgrade. You can deploy the new version without stopping the existing application and once the new version deployed successfully you can switch over transparently from the old one to new one.

I am not sure if other application server supports this.

Ref: http://edocs.bea.com/wls/docs100/deployment/redeploy.html#wp1022490

Answer 3

Vladimir's suggestion around using a load balancer is a pretty sure way of achieving what you want. Keep in mind, it need not necessarily be a high-end hardware load balancer. Rather, if you front your JBoss server with a native web server (Apache or IIS) and mod_jk or mod_proxy, you can maintain one common web facade and implement the applicable loading and routing routines at EAR upgrade time.

//Nicholas

Answer 4

I think you might want to look into Spring using OSGI framework. http://www.springframework.org/osgi