[keycloak-dev] Application Clustering problems
Christian Beikov
christian.beikov at gmail.com
Tue Jan 26 06:55:23 EST 2016
I am really sorry about the last mail, I just felt that my suggestions
about a possible problem were ignored, especially since you just
suggested to google it.
In the end I found out that I was missing the <distributable/> tag in my
web.xml to enable session replication properly. So you(Stian) were right
after all. I didn't quite get the hint that "need to enable it for your
application" actually meant that I had to change the web.xml.
Could you maybe put a warning into the documentation?
Sorry for the noise again.
Regards,
Christian
Am 26.01.2016 um 08:49 schrieb Stian Thorgersen:
> I don't see the need for this mail. I was actually trying to help you.
> I doubt you've even looked at what I've suggested though.
>
> As Bill points out get your HTTP session replication working first. It
> has nothing to do with Keycloak. If you want non-sticky sessions and
> not using the stateless option then you need that working. The reason
> why I told you to google it is that you do actually have to enable
> HTTP session replication on a per-war basis. It's not just a container
> config. The standalone-ha.xml config in WildFly should be fine by
> default, so you don't need to do anything there.
>
> On 25 January 2016 at 20:33, Christian Beikov
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> 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 <mailto: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
>>> <mailto: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
>>>> <mailto: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
>>>>> <mailto: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
>>>>> <mailto: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/20160126/0a9dd2da/attachment-0001.html
More information about the keycloak-dev
mailing list