Update an application in a production environment without stopping the application

[jprio]

Hello,

TC7 and Weblogic offer this very interesting feature (beeing able to upgrade an application without service loss).

For more details :

• http://middlewaremagic.com/weblogic/?p=394
• http://www.objectpartners.com/2012/04/17/tomcat-v7-parallel-deployment/

A quote from the second paper to illustrate : "Something that has long plagued web development is a difficulty updating running applications. The typical operation is to cut users off from the application (sometimes brutally), stop the running application, un-deploy the current version, deploy a new version, start the new version, and finally allow users to return to the application. In some cases it’s possible to re-deploy applications in place, but it will usually still result in an interruption to the user as the application is cleaned and restarted. The Apache Tomcat v7 brings with it a feature called Parallel Deployment, which allows deploying more than one application to the same context. This feature allows any activities going on with a session-based application to continue interacting with the “old” version even as a new version is deployed. This results in an effective zero-downtime solution, as long as your app behaves."

Is there such a feature in Wildfly ?

[jprio]

Anyone ?

[rhusar]

The way to do this on standalone WildFly is to:

1. start a new AS node, deploy new version of the application
2. go to mod_cluster manager console, disable the context with the old version
3. drain all sessions from the old version of the application
4. remove the old instance

If you already running in HA mode and the session data is compatible through new and old version of the application:

1. drain sessions from 1st cluster node
2. upgrade application, bring node back
3. repeat for all servers

If you are running HA mode but the session data is incompatible:

1. same as above, with the exception that the servers are being added back to different cluster with a different load-balancing-group so that session data doesn't clash.

Also note that neither of the solutions, including the ones you described, account for the situation when e.g. the database structure changes.

[jprio]

Thank you Radoslav,

Our way to achieve this goal with JB7 (domain mode) is : version 1 is deployed to ServerGroup1, we create ServerGroup2 (with some JB7 instances), deploy version 2 to ServerGroup2, wait some time for session replication between all servers (session data is compatible) and then kill ServerGroup1. User are 'transparently' migrating from version1 to version2. This works, but I think Tomcat's way is really more straightforward : they deploy foo##a.war and foo##b.war in the existing infrastructure and, when foo##b.war is deployed, foo##a.war can be killed. Our method involves the creation of server groups, server configurations, port offsets, the cleanup, ...

[rhusar]

Our way to achieve this goal with JB7 (domain mode) is : version 1 is deployed to ServerGroup1, we create ServerGroup2 (with some JB7 instances), deploy version 2 to ServerGroup2, wait some time for session replication between all servers (session data is compatible)

So that's pretty much the 2nd approach.

and then kill ServerGroup1

Well, don't kill the server. Imagine a request that has been already received by the server and the server is killed in the middle of its execution. The client is going to get 500 which is not retriable. This is solved using the mentioned draining approach.

This works, but I think Tomcat's way is really more straightforward : they deploy foo##a.war and foo##b.war in the existing infrastructure and, when foo##b.war is deployed, foo##a.war can be killed.

Sure, that sounds easier. Well, but it is not universal approach, i.e. doesn't solve the session compatibility. Also, it needs to synchronize and hold off new requests while the ones being processed on the old version is processed. Only hen atomically switch the context. This could temporarily increase response time for some clients, which is probably not that big of an issue.

Probably similar could be achieved by rolling app-v1.war, alond with app-v2.war and have a filter in Undertow  (since WildFly 8) that picks the newest context.

[jprio]

"kill ServerGroup1"

well, hum, "kill" is not the right word. "stop" the server, so that failover may work effectivel.

Session compatibility is not a problem in our case : we apply such a procedure just in case of the delivery of a patch in the middle of a day (not involving sessions data nor database structure modification).

There is aslo another drawback in our approch : we need to have a box with enough ram/cpu to host 2 jb7 instances just for a few minutes.

"Undertow filter" approch : is it possible to "hot-configure" such a filter ?

[rhusar]

well, hum, "kill" is not the right word. "stop" the server, so that failover may work effectivel.

Even in case of stopping a client can hit error 500, so still not 100% safe.

There is aslo another drawback in our approch : we need to have a box with enough ram/cpu to host 2 jb7 instances just for a few minutes.

True.

"Undertow filter" approch : is it possible to "hot-configure" such a filter ?

I don't think so, the filter/handler would have to be there all the time (something like a mod_rewrite).

[jprio]

Anyway, I perfer not to develop a custom solution.  I'm sure I'm not the only one to have this requirement ! Hot-patching a webapp must be a very common need, no ?

No chance to see such a feature ootb some day in Wildfly/Undertow ?

[rishikesh_darandale]

I also have similar requirement where I need to do deployment without stopping the application.  I have WF8 configured in domain mode and having one server group with 3 server nodes.

How should I do deployment this server-group without stopping the application deployed on it?

[bgueye]

Hello,

I have the same probleme in my application now in production the context :

In our stage we need to install a patch of web-app without stopping application, actually we using scrpting sh to

1 - Create new server-group named version of the patch

2 - Create server-config to server-group

3 - Deploy the new webapp-patch to this server-group with the same runtime name of the running webapp.

4 - Stopping the old server-group

5 - Remove the old server-group

It's so difficult to maintain this and not 100% reliable we have some proxy error during stopping.

Can somme body help us Or have an idea or tools to deploy in production without stopping running application.

[tsippert]

I have the same issue, and also think that a lot of people have that issue that jprio has.

The approach used by Tomcat is very elegant, just naming the versions of an application with ##001, ##002 and so on.

Since creating a new server-group each time a new version of an application is deployed takes a lot of time, I also suggest the approach explained before.

Ps: If someone have some kind of solution that doesn't involves creating new server-groups or that's easier and more transparent, please let me know.

Thank's

[stephen.batty]

We did this in jboss by simply deleting/moving the depoyed ear. This undeploys the artifact.  A new one can then simply be copied into the application. We assumed the sessions just became invalid.

Having similar funcitonaity to weblgoic/tomcat should be a number one priority imho for wildfly.,

[xxlali]

Is there any progress about this problem. I am using Wildfly-10.

[tizo]

It would be really useful for us to have this feature implemented in JBoss too. Meanwhile, I am trying to understand the alternative presented here, and trying to figure out how we can apply it in our environment, where we have several EARs with EJBs and several WARs that use the former ones. Besides, some of the EJBs depends on others EJBs too.

So, I guess that, given our situation, we cannot apply the two server-groups approach as presented here (as one of the projects in one server group, cannot depends on another project in another server group, right?). Which could be a good approach to apply on these cases?.

Thanks very much.