2

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!

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
László Tóth
  • 483
  • 5
  • 15
  • 1
    Wrt view scope and back buttons: just disable browser cache on dynamic pages and never use POST for page-to-page navigation. Related: https://stackoverflow.com/q/9930900 and https://stackoverflow.com/q/15521451 – BalusC Jul 12 '23 at 10:57

1 Answers1

3

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
Jonathan S. Fisher
  • 8,189
  • 6
  • 46
  • 84
  • How can you force the replication node by node? And send ViewScoped beans too he other side? What is kb session size? We works with wildfly, but I think if it works on tomcat will work on wildfly too... – László Tóth Jul 11 '23 at 21:17
  • So you don't "force the replication node by node". That's not a correct mental model for how replication works. Each strategy works in a slightly different manner. Take for instance redex-sm. At the end of the request is pushes the serialized session into Redis. On the next request, if a server doesn't have the sesssion in memory, it pulls the latest version from Redis, then tells the other servers to discard their copy – Jonathan S. Fisher Jul 11 '23 at 21:26
  • Yes this works with SessionScoped Beans, therefore ViewScoped beans (which are both stored in the Session). All parts of the Session are serialized and stored. – Jonathan S. Fisher Jul 11 '23 at 21:27
  • 1
    Here is a similar question/answer for Wildfly: https://stackoverflow.com/questions/56667426/how-to-externalise-httpsession-from-wildfly-to-redis-w-o-spring-session – Jonathan S. Fisher Jul 11 '23 at 21:32