|
Replies:
9
-
Last Post:
May 23, 2008 5:35 AM
by: roisinflannery
|
|
|
|
|
|
|
Deploy with no impact on current user sessions
Posted:
Mar 19, 2008 1:53 AM
|
|
|
For a 7x24 production environment, is GlassFish able to deploy new application patch without affecting concurrent user sessions? I understand that deployment do not require restarting the server. But I hope deployment do not lead to any service suspensions or interruptions, i.e. user session is kept and no relogin is needed; and the deployment is totally transparent to users. Is GlassFish able to provide this feature?
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 19, 2008 6:54 AM
in response to: anfernee_duo
|
|
|
I would like to add a more focused question: Does GF serialize running sessions before a redeploy, and does GF deserialize them afterwards?
Apart from Glassfish, there are hard limits on what you can change in an application while keeping a user session running, both when changing the domain logic and on the class loading level. If the change is not within these limits, no server can keep the user session. As a rule of thumb, small defect fixes can be restricted within these limits, new or changed functions are over the limit.
In the domain logic, for instance, you cannot change pre- or postconditions of user actions. Say step A (old) ensures that a condition X holds, and step B (old) relies on X. Now you change this structure, say A (new) ensures Y as well, and B (new) assumes X and Y. If you migrate a user session after step A (old) to the new implementation, the next step B (new) will fail, because Y does not hold.
Technically, all session information is managed as instances of classes in the server. Whenever a new application is deployed, a new class loader instance reads the new archive file and loads new classes. The information of running sessions, however, uses instances of the old classes, loaded from the old version of the archive file.
The only way to migrate the session information that I can think of is as follows:
1) serialize the user session with the old classes
2) deserialize with the new classes
Of course, this will only work if no new information is needed in the new version (which would be a change in domain logic), and if the classes have the same serialized form on the Java level, for example the same serial version ID.
So the question again: given the domain logic does not change (too much) and the classes are kept compatibel with respect to serialization, does GF migrate the user sessions?
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 19, 2008 11:36 AM
in response to: wfrech
|
|
|
GlassFish v2 destroys a web application's session manager and all its sessions when the web application is redeployed. A redeploy is nothing other than an undeploy (which removes any traces of the web application from the domain/cluster), followed by a deploy.
There is work planned for GlassFish v3 to support versioning of applications, where it will be possible to upgrade from one version of a web application to another, without having to stop and restart an instance (during a rolling upgrade in a cluster), and without the need for redeployment: The administrator will be able to "switch" from the active version of an application to another deployed version of the same application. This will also allow any of the application's active sessions to be preserved and migrated to the new version of the application. As you've pointed out, the migrated sessions will have to be externalized (serialized) and then loaded by the classloader associated with the new version of the application.
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 25, 2008 3:34 AM
in response to: jluehe
|
|
|
Thanks jluehe,
So currently, a redeploy has an impact on the user session, because the session is destroyed.
In GF v3, a new feature is planned to be able to preserve the user session, though it will be a bit more sophisticated than a plain redeploy.
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 25, 2008 5:17 PM
in response to: wfrech
|
|
|
Yes, a redeploy removes any and all traces of a webapp, including its sessions. This will continue to be true in v3.
However, in v3, you will be able to deploy different versions of the same webapp "side-by-side", and upgrade from one version to another without the need for a redeploy, which will allow any of the webapp's active sessions to be preserved.
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 25, 2008 9:50 PM
in response to: jluehe
|
|
|
Is that really the case? That the server will somehow migrate sessions across versions? Or will it be more of a "current users use version 1 of the app, new users route to version 2, when all users are done with version 1 it can be safely undeployed". That's a different approach to the problem.
The first technique also implies some kind of migration lifecycle event that is going to allow the application to migrate the session (otherwise, it's a Bad Idea), the second technique mitigates that problem since it will only see "new" sessions and not have to convert old ones.
Finally, of course, there is the issue of having to overscale the server to handle both workloads (the old and new application simultaneously), so that's an impact that will have to be considered when using either technique. In theory the user load would "be the same", but you have two instances of the server running (and there may be substantial caching and other memory pressure).
Also, what consideration is being given to if I have two versions of an application within a cluster, version 1 on instance A and version 2 on instance B and the ramifications regarding session failover from a version 1 instance to a version 2 instance, or do we lose that ability?
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 26, 2008 8:35 AM
in response to: whartung
|
|
|
The deployment team is still in the process of discussing the exact details of how the upgrade will be implemented, but from what I remember, the switch from one version of the app to another will occur for both existing and new users at the same time. There is going to be a new admin event that will make the switch occur. In response to this event, any existing active sessions will have to be serialized, and later deserialized by the classloader of the new version of the app. Of course, the (custom) class definitions of any of the app's session attributes must be backwards compatible across the app's versions for this (and session failover) to (continue to) work.
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 26, 2008 2:24 PM
in response to: jluehe
|
|
|
The container is going to HAVE to do some kind of call back to allow the application to update the session during the upgrade. There are issues that may not be resolved simply through serializing and deserializing the class. A contrived example could be that the application injects something in to the session when a user logs in.
In the old version, this feature didn't exist. In the new version, this feature is assumed. If the application doesn't have an opportunity to upgrade the session and load this item in to the session, then the new application may well be working with an invalid session state that it's simply not designed to handle gracefully.
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
Mar 26, 2008 6:04 PM
in response to: whartung
|
|
|
Good question!
I think the kind of callback you mention already exists.
If the app foresees the needs to inject session state during the upgrade, it could store a custom session attribute implementing the HttpSessionActivationListener interface in all of its sessions (this could be done by the sessionCreated() method of the app's HttpSessionListener) .
The HttpSessionActivationListener implementation could invoke a static method (that implements any required upgrade logic and takes a session as its argument) on one of the app's implementation classes, whose implementation could be different in the new version of the app.
Then, as each session is restored during the upgrade, its HttpSessionActivationListener attribute will be invoked at its sessionDidActivate() method, and could invoke the new upgrade logic, by passing it the session received in the HttpSessionEvent.
I have not thought this thru in detail, but it looks like this might work. What do you think?
|
|
|
|
|
|
|
|
|
Re: Deploy with no impact on current user sessions
Posted:
May 23, 2008 5:35 AM
in response to: anfernee_duo
|
|
|
Hi anfernee_duo,
Have you ever considered purchasing a support contract with Sun? We have a number of different offerings and pricing schemes, to support every type of user.
With support, you receive access to fully tested and supported patches, containing fixes to recent bugs. You also will have the benefits of up to 24x7 support, meaning that you can get your questions answered all the time anytime. Please take a look at the following link for more details:
http://forums.java.net/jive/thread.jspa?messageID=276262񃜦
or else, please feel free to reply to this thread and I will provide more information.
Kind regards,
Roisin
Sustaining Engineering, GlassFish
|
|
|
|
|
java.net RSS
