Horizontal scaling of JSF 2.0 application

Question

Given that JavaServer Faces is inherently stateful on the server side, what methods are recommended for horizontally scaling a JSF 2.0 application?

If an application runs multiple JSF servers, I can imagine the following scenarios:

1. Sticky Sessions: send all requests matching a given session to the same server.
   • Question: what technology is commonly used to achieve this?
   • Problem: server failure results in lost sessions... and generally seems like fragile architecture, especially when starting fresh (not trying to scale an existing application)
2. State (Session) Replication: replicate JSF state on all JSF servers in cluster
   • Question: what technology is commonly used to achieve this?
   • Problem: does not scale. total memory of cluster = total memory on smallest server
3. Instruct JSF (via configuration) to store its state on an external resource (e.g. another server running a very fast in-memory database), then access that resource from the JSF servers when application state is needed?
   • Question: is this possible?
4. Instruct JSF (via configuration) to be stateless?
   • Question: is this possible?

[EDIT]

Updated in response to Ravi's suggestion of Sticky Sessions

Answer 1

This can be achieved by configuring your load balancer in sticky session mode.

More info

This way all your subsequent requests are sent to the same application server.

Answer 2

Here's an idea from Jelastic PaaS:

Pair-up application instances in 2-server clusters, and apply session replication between those 2 instances within one cluster. Then you can add as many 2-instance clusters as you want and load balance requests between clusters, with each session sticking to the cluster it originated from. Within cluster, requests could be load balanced between instances.

This way there is some degree of fail safety, since if one instance in cluster fails, the other takes over, with same session state. On the other hand, memory impact is not as severe as with full replication.

In short, it is combination of 1. and 2. from your question. Of course, there can be more than 2 instances in each cluster, if availability is of greater concern.

Link to Jelastic docs I lifted the idea from: http://jelastic.com/docs/session-replication.

Disclaimer: I don't actually know how to configure this with JSF2, and have no affiliation with Jelastic. Just liked the idea and thought it might help.

Answer 3

What about session replication with "buddy" semantics?

With one buddy total memory is halved (every server needs to hold the session data of two servers), which is a lot better than having to hold data of each and every server out there.

Buddy replication also reduces bandwidth overhead.