Hi, On Wed, Jul 3, 2019 at 8:32 PM Manfred Bergmann <m...@software-by-mabe.com> wrote:
> I mean, don't get me wrong. > I'm in favour of session stickiness and I can't understand why this is not > preferred. > > But anyway. If we have aTCP load-balancer that switches on a timely basis > every 200ms then session replication doesn't really work, or? > > A mix of session stickiness and session replication is the recommended approach. Session stickiness works fine as long as the node is alive. If for some reason the node goes down then the load balancer moves the client to another node. Session replication is for the fallback case when the client is redirected to another node for any reason. As you pointed out there is no guarantee that the replication would have finished before the next request. This is something normal in distributed systems. The first request to the second node may use stale session data but the next request most probably will see the correct/replicated one. There is a chance for bigger problems too - if the 1st request on the new node saves the stale session then the web container will override the replicated one and some data might get lost. The general recommendation is to keep your sessions as light as possible, so that they can be (de)serialized as fast as possible and avoid such problems. > -- > Sent from: > http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
