[keycloak-dev] Application Clustering problems

Wed Jan 27 03:50:48 EST 2016

A note is sufficient IMO. We shouldn't go over board with documenting
things that should be covered elsewhere. It's not our responsibility to
document how to cluster a WAR.

On 26 January 2016 at 22:05, Marek Posolda <mposolda at redhat.com> wrote:

> Yeah. The question is where is the exactly is the "border" to provide some
> hints, but not duplicate the info, which is not directly related to
> Keycloak.
>
> For application clustering, it's tricky as we support bunch of servers for
> adapter clustering. And each of them has some differences for cluster setup
> (and different infinispan version). So I've just added the note about
> <distributable /> in web.xml and the obligatory sentence "For more details
> look at your app server documentation" :-)
>
> Hope this will be sufficient for most of the cases.
>
> Marek
>
>
> On 26/01/16 18:10, Marko Strukelj wrote:
>
>> Maybe we should assume that people forget that stuff, and some don't
>> know it in the first place, and simply try to give all the info
>> necessary even for novice java developer to be successful setting it
>> all up.
>>
>> On Tue, Jan 26, 2016 at 5:36 PM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I've put some small note at the first paragraph of "Application
>>> clustering"
>>> chapter. Just a small note really, as setup of "distributable" in
>>> web.xml or
>>> configuration of infinispan are app. server specific steps and they are
>>> general to HttpSession replication and clustering, it's not Keycloak
>>> specific stuff.
>>>
>>> Marek
>>>
>>>
>>> On 26/01/16 12:55, Christian Beikov wrote:
>>>
>>> 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>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160127/9cde5f4a/attachment-0001.html 