Search code examples
jsfhigh-availabilityrolling-deployment

Is possible achieve rolling deploy (and HA) with JSF application?

I think the main problem with JSF is: hard to achieve rolling deploy.

With stateless restapi + js frameworks you can stop some servers and upgrade it while other servers works and there is no or minimum downtime.

Our JSF applications are scaleable, there are 4-8 servers, but one user can work with just one node (stickysession loadbalancing)

After jsf support browser's back button with ViewScope the Session replication can be just a dream... Or not?

I would achive zero downtime application upgrade. (And high(er)-availability too)

Is any method, or design principle to achieve: user redirection to another node? With or without sessionreplication. Thanks a lot!

Solution

  • Yes absolutely this is possible and we do it today for HA and seamless/fearless deployments and rollbacks.

    Assuming you're on Tomcat or a derivative, you can use anyone one of the replicated SessionManagers to serialize the sessions and move them around the cluster. However, every major JEE server has a way to replicate sessions around a cluster. I'll stick to Tomcat for this answer as it's what I know, but the concepts are similar for any server.

    The simplest possible SessionReplication is JDBC based. This simply writes the users' sessions to a database table.

    Other replication strategies are available, such as direct TCP connections between the servers.

    See the entire Tomcat documentation here: https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

    We found JDBC to be a bit slow, and direct TCP a bit hard to manage, so we wrote a Tomcat SessionManager that writes to Redis and only adds a few ms (8ms-12ms) to each request: https://github.com/exabrial/redex-sm

    We got inspiration from this Session Replication implementation: https://redisson.org/glossary/tomcat-web-session-replication.html

    You should continue to use Sticky Sessions, but make sure your Load Balancer is set to "redispatch" mode or equiv for your load balancer. What this does is retries the user's request on another server and rewrites their sticky cookie upon server failure. This allows you to perform a rolling deploy and the users sessions are moved from server to server seamlessly.

    We use haproxy, so the redispatch option looks like this:

    retry-on 503 0rtt-rejected conn-failure
option httpchk