[
https://jira.jboss.org/jira/browse/MODCLUSTER-144?page=com.atlassian.jira...
]
Brett Cave commented on MODCLUSTER-144:
---------------------------------------
I am not sure if this is what it is for - domain will ensure that incoming requests to 1
httpd server will always be routed to the same domain, as far as I understand.
Given this scenario:
4 x JBoss AS servers, non-clustered (each on its own domain), jbA, jbB, jbC and jbD
2 x httpd servers - httpA and httpB distribute load with mod_cluster equally to the 4 JB
servers.
1 x session-aware load balancer (LB1) in front of httpd servers, distributing incoming
connections between httpdA and httpdB
client1 connects to LB1. LB1 routes connection to httpA and notes affinity. httpA connects
client to jbC and notes affinity. Client will always hit httpA -> jbC.
httpA is shut down. lb1 now routes client1 -> httpB. httpB is not aware of client's
affinity to jbC, so routes client to jbA. Client's session is lost.
if jbA and jbB were on cluster partitionA and jbC and jbD on partitionB, the domain
property could be used to ensure that httpA always routed to partitionA and httpB routed
to partitionB ?
Affinity replication between multiple mod_cluster servers
---------------------------------------------------------
Key: MODCLUSTER-144
URL:
https://jira.jboss.org/jira/browse/MODCLUSTER-144
Project: mod_cluster
Issue Type: Feature Request
Affects Versions: 1.1.0.CR1
Environment: ec2 or centos5.4 + apache2.2.3 + JBoss AS 5.1.0.GA
Reporter: Brett Cave
Assignee: Jean-Frederic Clere
mod_cluster maintains affinity (aka session stickiness) between clients and application
servers. However, if scaling up or down number of http / frontend servers running
mod_cluster, a client may be directed to 1 server intitially and then be directed to
another frontend later (depending on connection distribution in front of http servers). If
this occurs, other http servers are not aware of each other's affinity, and so there
is a chance that (if session is not replicated on jboss as servers) a clients session will
be lost if he is migrated to a new http server. This would be particularly applicable in a
cluster consisting of a number of buddy partitions fronted by >1 mod_cluster http
servers.
Not sure about implmentation, but if the mod_cluster.sar service could report relevant
info required to maintain affinity back to all frontend servers, a higher level of fault
tolerance could be achieved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira