[keycloak-dev] Application Clustering problems
Christian Beikov
christian.beikov at gmail.com
Mon Jan 25 16:25:44 EST 2016
By "pretty sure" I mean that replication is working perfectly fine for
similar cache containers.
The default configuration for the session replication mode in Wildfly
10 is asynchronous so I guess the reason for my problems is the
replication lag then.
I will try it out then and let you know for sure, but as far as I
understand the problem, the only possible solutions are to either
configure synchronous session replication or asynchronous session
replication in combination with sticky sessions. Hopefully you can add a
warning to the user manual so that other users don't run into the same
problems.
Am 25.01.2016 um 21:58 schrieb Bill Burke:
> What do you mean by you're "pretty sure clustering/session replication
> is configured correctly". Either its working or it isn't. Have you
> tested a simple application WITHOUT keycloak and with Round Robin to
> determine if replication is set? Because from what you are
> describing and what Stian said to you over and over again is that it
> does not look like HTTP session replication is working for you.
> Keycloak client adapter stores that you are authenticated within the
> HttpSession. It is possible that session replication is lagging I
> think...only if you have async replication turned on. I don't know
> what the default is in Wildfly 10.
>
> Also, a forbidden exception might mean that your web.xml requires a
> role set for the user for the URL you are accessing and the user does
> not have that role assigned to them.
>
> On 1/25/2016 2:33 PM, Christian Beikov wrote:
>> I don't want to be rude but you aren't helping me at all so I'd like
>> to ask someone else from the team about this. I tried to explain
>> multiple times that I already configured clustering in my Wildfly
>> server, thus I configured session replication.
>> Either I don't understand something about session replication or I
>> require a configuration that you don't mention anywhere.
>> I copied over the cache container from the standalone-ha
>> configurations and configured the JGroups Subsystem which is what is
>> described in the official documentation:
>> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>>
>> I think I gave you enough information about my situation which you
>> seemed to ignore completely. I would very much appreciate if I got a
>> clear answer to my question especially since I am not asking for
>> general configuration help, but for this special case which to me
>> seems like a problem/limitation that should be explicitly documented.
>>
>> I am pretty sure clustering/session replication is configured
>> correctly since I am using a custom cache container with a similar
>> configuration like the web cache container which I know replicates
>> correctly. So here comes my question once again, is it possible that
>> the replication just lags behind which makes the usage of round robin
>> completely impossible in the login flow? Or is there some kind of
>> special configuration I have to do which differs from the standard
>> cluster configuration as provided by the wildfly distribution? Or is
>> this maybe even an implementation limiation of the server adapter?
>>
>> Regards,
>> Christian
>>
>> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>> Try google for wildfly replicate http sessions
>>>
>>> On 25 January 2016 at 15:53, Christian Beikov
>>> <christian.beikov at gmail.com> wrote:
>>>
>>> I just wrote that I configured clustering for my application
>>> just like in the standlone-ha.xml of my Wildfly 10 CR4.
>>> I configured the jgroups subsystem and the distributed caches
>>> for web sessions as it is done in standalone-ha.xml of Wildfly.
>>> If there is anything else that should be configured, can you
>>> please point me to that configuration option?
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>> HTTP session replicate is not enabled by default. You need to
>>>> enable it for your application.
>>>>
>>>> On 25 January 2016 at 14:39, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>
>>>> The documentation states, that the default token-store is
>>>> "session" and as I wrote before, I have setup clustering on
>>>> my Wildfly 10 CR4 like in standalone-ha.xml, so the session
>>>> should already be replicated.
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>> Your issue doesn't have anything to do with the Keycloak
>>>>> server side user sessions, they don't require sticky
>>>>> sessions.
>>>>>
>>>>> Your issue is down to the http session on the adapter side
>>>>> not being replicated by default. For the adapter you've
>>>>> got 3 choices: sticky session, replicated session or
>>>>> stateless. Which is best depends on your application.
>>>>>
>>>>>
>>>>> On 25 January 2016 at 14:05, Christian Beikov
>>>>> <christian.beikov at gmail.com> wrote:
>>>>>
>>>>> I don't have a problem with sticky sessions and I will
>>>>> definitively configure them, but I am curious. What is
>>>>> the reason for the problems with round robin in this
>>>>> test scenario? Are the infinispan caches not
>>>>> replicated fast enough or is there an implementation
>>>>> limitation in the adapters?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>> By default the adapters will require sticky sessions,
>>>>>> please refer to
>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>> for more information
>>>>>>
>>>>>> On 22 January 2016 at 12:48, Christian Beikov
>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am running some tests with my application
>>>>>> cluster being secured by a
>>>>>> single keycloak server instance and I encountered
>>>>>> problems with the adapter.
>>>>>>
>>>>>> My application cluster contains 2 nodes and is
>>>>>> load balanced by nginx.
>>>>>> For testing purposes, I enabled round robin load
>>>>>> balancing which is
>>>>>> probably the "cause" for my issues.
>>>>>>
>>>>>> When I access a secured page, I get redirected to
>>>>>> keycloak and
>>>>>> everything is fine. When I then login, and
>>>>>> keycloak redirects me back to
>>>>>> the application, I get to a different application
>>>>>> cluster node because
>>>>>> of round robin. On that node, apparently the
>>>>>> initial information of the
>>>>>> client session is not available and I get
>>>>>> redirected to keycloak login
>>>>>> page again. Then keycloak redirects me back to
>>>>>> the application, this
>>>>>> time to the original node, and says that access
>>>>>> is forbidden.
>>>>>>
>>>>>> I suppose the web session caches are not in sync
>>>>>> but I just used the
>>>>>> default cache containers as they are defined in
>>>>>> standalone-ha.xml of my
>>>>>> Wildlfy 10 CR4. Clustering with jgroups works, as
>>>>>> I use other
>>>>>> distributed caches too which work just fine.
>>>>>>
>>>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>> _______________________________________________
>>>>>> 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
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/938fec2f/attachment-0001.html
More information about the keycloak-dev
mailing list