This doesn't work currently, as the apache mod-cluster instances don't
exchange information about their states, e.g. which sticky session is
routed to which worker.
No wait, I guess I'm wrong: they don't need to !
Say we have Apaches A1 and A2, and workers W1, W2 and W3.
If a client request hits A2 and A2 creates a new session on W3, then the
session id is going to be SESSION.W3. When the same client now hits A1,
A1 should actually also route the request to W3 ! This of course assumes
that all workers have registered with all Apache daemons.
So IMO we don't even need to exchange routing information between the
Apache daemons... can someone confirm this ?
This is with sticky session. If you turn this off, you can pick any
Apache to route your request, and the route will be different every
time. In this case, you'd have to use synchronous replication to prevent
potentially stale data between 2 requests for the same session going to
different workers.
With Infinispan and DIST, stale data shouldn't be an issue as the
routing is always based on the content (keys to be accesssed) rather
than a client's identity (session-id), and L1 caches should make things
fast, so data doesn't have to be fetched by one worker from another one.
Marek Goldmann wrote:
Hi all,
One of JBoss Cloud users asked me about possible clustering of our
front-end appliances. This in real is the question: can we have
multiple mod_cluster instances that share state between them?
If this is possible how I can configure it? If this is not possible
now, is it maybe in roadmap?
This could greatly enhance HA of web clusters. How? For example we
have an Elastic Load Balancer in Amazon. It doesn't support sticky
sessions and it just forwards requests to selected instances. If we
could for example forward it to two our clustered front-end appliances
we could achieve great failover.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss