You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bergmann Manfred <mb...@software-by-mabe.com> on 2019/07/03 09:15:21 UTC
Best practice for session handling - high availability
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 more cookies (which are encrypted) and such.
Is that something that is actually being done in practice?
It basically would not require session replication in the background and could work without session stickiness.
Session size. In middle sized web applications with a JavaScript enabled components.
Or actually generally, what is a session size that is ideal, or good to replicate?
What is your experience?
Regards,
Manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for session handling - high availability
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Jul 3, 2019 at 8:32 PM Manfred Bergmann <mb...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Best practice for session handling - high availability
Posted by Manfred Bergmann <mb...@software-by-mabe.com>.
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.nabble.com/Users-forum-f1842947.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for session handling - high availability
Posted by Manfred Bergmann <mb...@software-by-mabe.com>.
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
that?
Regards,
Manfred
Andrea Del Bene-3 wrote
> 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 example Apache Ignite:
>
> https://apacheignite-mix.readme.io/docs/web-session-clustering
>
> If you go for such kind of solution you should also choose to save page
> instances directly into HttpSession, so everything can be cached into
> Ignite:
>
> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_httpsessiondatastore
>
> On Wed, Jul 3, 2019 at 11:15 AM Bergmann Manfred <
> mb@
> >
> wrote:
>
>> 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 more cookies (which are
>> encrypted) and such.
>> Is that something that is actually being done in practice?
>> It basically would not require session replication in the background and
>> could work without session stickiness.
>>
>> Session size. In middle sized web applications with a JavaScript enabled
>> components.
>> Or actually generally, what is a session size that is ideal, or good to
>> replicate?
>>
>> What is your experience?
>>
>>
>>
>> Regards,
>> Manfred
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>> For additional commands, e-mail:
> users-help@.apache
>>
>>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for session handling - high availability
Posted by Andrea Del Bene <an...@gmail.com>.
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 example Apache Ignite:
https://apacheignite-mix.readme.io/docs/web-session-clustering
If you go for such kind of solution you should also choose to save page
instances directly into HttpSession, so everything can be cached into
Ignite:
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_httpsessiondatastore
On Wed, Jul 3, 2019 at 11:15 AM Bergmann Manfred <mb...@software-by-mabe.com>
wrote:
> 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 more cookies (which are
> encrypted) and such.
> Is that something that is actually being done in practice?
> It basically would not require session replication in the background and
> could work without session stickiness.
>
> Session size. In middle sized web applications with a JavaScript enabled
> components.
> Or actually generally, what is a session size that is ideal, or good to
> replicate?
>
> What is your experience?
>
>
>
> Regards,
> Manfred
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Andrea Del Bene.
Apache Wicket committer.