Dominique CLAIRAC commented on MODCLUSTER-71:
We have the same problem.
On JBoss side, we have two server groups (A and B) with two JBoss Full-HA servers in each
On mod_cluster side:
- Each server of a same server group is declared in an unique
"load-balancing-group", so we have 2 LBGroup with 2 nodes in each.
- Requests are routed to goup A or Group B, depending on the load and session affinity.
During an application update:
- We disable the Node B to drain sessions to the node A.
- We then update the application with the new version on server group B with
autoEnableContexts = false (It should be better to have stopped status than disabled when
autoEnableContexts is false, because application is still accessible for someone with node
JVM_ROOT in an old JSESSION_ID).
Then we would like administrators to test the application before draining requests from A
to B (new version activation).
After reflection, I would suggest something like this:
On JBoss side, possibility that the application is declared as STOPPED rather than
DISABLED on deployment
On cluster_manager UI: ability to generate a token associated with a server or LB group,
which will be stored in a cookie.
On request with this token, mod_cluster must send the request to the node or the LB group
associated to the token, even if the application is marked as STOPPED on it.
Ability to declare an IP range as the test network in mod_cluster apache configuration
(eg: mod_cluster_test_network = 192.168.174.0)
Have a property (eg "test_mode") in the mod_cluster subsystem on jboss side.
If test_mode is true, only requests from the mod_cluster_test_network network can reach
the server in question)
Whith this solution, we juste have to change the value of "test_mode" on jboss
conf to achieve our goal
Handle multiple versions of the same webapp
Issue Type: Feature Request
Reporter: Brian Stansberry
Assignee: Jean-Frederic Clere
This is a big picture future roadmap kind of thing.
Assume the AS develops the ability to host two versions of the same webapp concurrently.
Imagine a workflow like this:
1) Version 1 is running, handling requests
2) Version 2 is deployed, is allowed to receive a low workload to validate that it works
3) Version 2 is shifted to allow full workload
4) Version 1 is put into disabled mode to drain sessions
5) Version 1. is undeployed.
Obviously making this work requires a lot of currently non-existent stuff in the AS.
Point of this JIRA is think about how to deal with it at the mod_cluster level.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira