[ https://issues.jboss.org/browse/MODCLUSTER-71?page=com.atlassian.jira.plu... ] 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 group. 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: Choice 1: 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. Choice 2: 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 -- 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