This content has been marked as final. Show 5 replies
Hey Chris --
OC4J doesn't implement the same side-by-side versioning approach that WLS does -- it's a nice facility from what I have seen of it. We should buy them if we ever get the chance .. :-) Their staged/admin-only deployment model is also very useful for deploy/test/publish scenarios.
In OracleAS 10.1.3.1+ we have the ability to execute a redeployment operation to a "group" of OC4J instances in a serial form.
When a sequential redeployment operation is executed, the cluster deployment handler:
1. Picks the first OC4J instance in the group.
1.1 The container STOPS the application
1.1.1 Signals to mod_oc4j to take it out of the route table so it doesn't get any new requests -- this happens dynamically with no restart required with OHS/mod_oc4j 10.1.3.
1.1.2 Allows all current inflight requests to finish, flushes any session state updates
1.2 The current version of the application is then undeployed
1.3 The new version of the application is deployed
1.4 The application is started
1.4.1 Signals to mod_oc4j that is available for service, dynamically added back into the routing mix.
1.5 Starts receiving and servicing requests
2. Group deployment mechanism waits for the specified timeout period.
3. Repeats the process for the remaining OC4J instances.
Since we have session affinity with OHS/mod_oc4j routing, any existing client requests will continue to go to their current instance unless it is stopped. So for customers on V1 of an application, they'll stay on it until it is upgraded. Any requests that get serviced by V2 of an application will continue to be serviced by that server/application, unless it is taken down for some reason.
For those applications that are maintaining client "state" within the server, if the application has configured state-replication, then any session state will be maintained on other nodes as the redeployment of a specific node occurs.
In earlier releases, this was documented in a far more manual fashion as something called a "cluster dance" -- where due to the automated synchronization when operating in a cluster, you needed to take instances out of one cluster into another to do the upgrade, then join them back together.
The sequential group deployment mechanism, IMHO offers a much simpler path to do a multiple instance redeployment while maintaining availability.
There's a general doc about this from the same author above here:
There's a screen cam/viewlet somewhere on OTN I believe that demos this as well.
And a fairly simple form of how-to here which walks you through an example:
Thanks for your reply Steve. Do you mind if I post a link to this discussion on my blog? I think a few people will find the discussion interesting.
Sure, its a public forum.
"Since we have session affinity with OHS/mod_oc4j routing, any existing client requests will continue to go to their current instance unless it is stopped. So for customers on V1 of an application, they'll stay on it until it is upgraded. Any requests that get serviced by V2 of an application will continue to be serviced by that server/application, unless it is taken down for some reason."
We have our application deployed to a 2-node cluster of OAS 10.1.3.3.0. I have setup OHS with 'roundrobin-local affinity'. There's only 1 JVM per node but the setting stops cross-node chatter. My question is, if a subsequent request in a session went to the wrong OHS, would it still be redirected correctly? If it helps, these are RPC calls from a GXT/GWT client?