Hi,
On Wed, Jul 3, 2019 at 8:32 PM Manfred Bergmann
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
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?
--
Sent from: http://apache-wicket.1842946.n4.n
Thanks for you reply.
I'm wondering to what extend saving the session and session replication will
really work if the load-balancer really switches x times per second on a
request with various JavaScript lazy load requests.
So the session replication must be blazingly fast. Can Ignite really do
th
Hi,
session is something that lives on server side, so there's no chance to
persist it on client. Besides, client solutions like cookies and
localStorage have size limits. What you should try to do is to adopt a
third solution that makes session clustering possible without needing
stickiness.
For
Hi.
I know a few points, like using LoadableDetachableModel’s to keep session size
low.
As it has to be replicated in some way between server nodes in a cluster, or
stored in a database.
Session stickiness is probably how most deployments work.
But what about offloading the session into one or
