[keycloak-dev] sticky sessions, clustering, and authentication
Marek Posolda
mposolda at redhat.com
Thu Jun 4 04:28:15 EDT 2015
On 4.6.2015 08:53, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "mike cirioli" <mikecirioli at gmail.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 4 June, 2015 8:49:03 AM
>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication
>>
>> Question is if the requirement for sticky sessions is not too
>> restrictive? I guess not everyone want to use sticky sessions.
>>
>> Maybe we should offer both possibilities (in-memory + sticky sessions OR
>> AuthenticationSession saved in infinispan and replicated after each
>> request) ?
>>
>> Another question is if overhead of current replication is really so bad
>> to introduce another abstraction and increase code complexity?
> We're not using a replicated cache - we're using a distributed cache.
>
> If anyone is worried about performance Google how Google works (hint: sharding) ;)
yeah, the performance is the question and at some point I want to look
at it a bit more. For the distributed I am a bit worried if it doesn't
require more network calls then replicated in some envs. I wonder about
the situation like:
1) You open login screen and you're forwarded by LB to node1 where is
ClientSession created and saved into cache
2) You confirm login screen but then you're forwarded by LB to node2.
Then call to "keycloakSession.sessions().getClientSession()" always
perform network call to node1 as my ClientSession is saved on node1. Or
am I wrong here?
So in shortcut, in distribution there is no any overhead with
replicating the session as it's saved always in one node, but there may
be much more overhead in lookup for sessions, which are saved on
different cluster node (unless I am wrong...)
Marek
>
>> Marek
>>
>> On 4.6.2015 01:49, mike cirioli wrote:
>>> So sticky sessions would be needed only during the authentication phase,
>>> and once complete an underlying clustered session would be created?
>>>
>>> On Jun 3, 2015 7:00 PM, Bill Burke <bburke at redhat.com> wrote:
>>>> I was thinking a bit about performance in a cluster. Right now a client
>>>> session is created whenever login is initiated. This ends up requiring
>>>> the client session to be propagated to the cluster, either through a
>>>> database insert/update or an infinispan replication. Then, with each
>>>> authentication/required action step, another insert/update/replication.
>>>>
>>>> I was thinking we should have an AuthenticationSession that was in
>>>> memory only. Then, once all authentication and required actions are
>>>> finished, then create the usersession and client session. This would
>>>> require sticky sessions though with a load balancer.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
More information about the keycloak-dev
mailing list