[keycloak-user] TCPPING problem.

[Sebastian Laskawiec]

On Mon, Feb 11, 2019 at 10:53 AM Vaclav Havlik <Johny.Dee at seznam.cz> wrote:

> Hello.
> sorry, after some investigation I got it to work. The problem seems to
> have been, that I have to use a concrete address in interface, not any-addr
> .
>

Yes! This is how TCPPING works:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/TCPPING.java#L25

There are some other, more dynamic protocols like MPING for the instance. I
would need to know more about your environment (bare meta/cloud/any network
traffic restrictions) to make a better suggestion.


>
> But here is another less problem.
> I have 2 instances of Keycloak on 2 different computers, namely
> 10.0.206.31 and 10.0.206.32 . Config files and log files are attached. I
> also use httpd load-balancer in front of them.
>
> It works very well with my specialized webapp called *web_app_clustering*,
> which is also attached . It is plain webapp, thus *JSESSIONID* is always
> sent.
>
> Now with Keycloak, I have set up a realm and *SPNEGO* & *TOTP*  to log
> into   */auth/realms/<realm>/account*  .  To goal is to keep the session
> and avoid TOTP form again.
>
> 1.
> Keycloak sends *AUTH_SESSION_ID*, *KEYCLOAK_IDENTITY* and
> *KEYCLOAK_SESSION*, and it is not 100% reliable. Sometimes , when I log
> in into one instance and then I start the other instance and stop the first
> instance, it empties the cookies and display TOTP form again. But sometimes
> it works.
>

If you're using 2 nodes and our default standalone-ha.xml, this is a kind
of behavior that may happen. Our distributed caches use number of owners
equal to 1. That means, there's only one copy of each session object in the
cache. If the owner of this item goes down (as a reminder - you use 2
nodes!), you lose that object.

Try increasing this to 2 or changing this cache to the replicated mode.

As a side note, I usually recommend running on odd number of nodes in
distributed systems. I would highly recommend running 3 instances of
Keycloak instead of 2.


>
> 2.
> I wanted to experiment with attribute mode ( SYNC / ASYNC ) of
> replicated-cache / distributed-cache, but it errors that there is no such
> attribute.
>

Yes, all caches in Wildfly are SYNC:
https://wildscribe.github.io/WildFly/13.0/subsystem/infinispan/cache-container/replicated-cache/index.html

And here's the explanation from the docs: "Deprecated. This attribute will
be ignored. All cache modes will be treated as SYNC. To perform
asynchronous cache operations, use Infinispan's asynchronous cache API."

Unfortunately it seems there is no way to set to ASYNC mode. However with
your test scenario ASYNC may lead to more inconsistencies. My
recommendation would be to stay with SYNC.


>
> I am also attaching timeouts for the realm.
>
> Thank you, Venca.
>
>
>
> ---------- Původní e-mail ----------
> Od: Sebastian Laskawiec <slaskawi at redhat.com>
> Komu: Vaclav Havlik <Johny.Dee at seznam.cz>
> Datum: 31. 1. 2019 13:42:35
> Předmět: Re: [keycloak-user] TCPPING problem.
>
> Hey Vaclav,
>
> Could you please send us your configuration xml (make sure you're using
> standalone-ha.xml) and output of your logs?
>
> Thanks,
> Sebastian
>
> On Thu, Jan 31, 2019 at 12:04 PM Vaclav Havlik <Johny.Dee at seznam.cz>
> wrote:
>
> > Dears,
> > I would like to ask a question.
> >
> > I have Wildfly, version WildFly Full 14.0.1.Final(http://14.0.1.final)
> > (WildFly Core 6.0.2.Final(http://6.0.2.final)) .
> > And then I have Keycloak, version Keycloak 4.7.0.Final(
> http://4.7.0.final)
> >
> > (WildFly Core 6.0.2.Final(http://6.0.2.final)) .
> >
> > Static cluster configuration, using TCPPING, works in Wildflys, but does
> > not
> > work in Keycloaks.
> >
> > I always have 2 instances on localhost (browser thus sends them the same
> > JSESSIONID). On both I have deployed a testing clustering webapp, with
> > which to test, if sessions are replicated. But Keycloaks do not pass
> > sessions to each other. I can see that when the page from the second
> > instance is reloaded in browser, it sends Set-Cookie header with another
> > cookie, as it obviously does not know the JSESSIONID from the first
> > instance.
> >
> > With Wildflys the same does work.
> >
> > Can you tell me, is there any reason, why this is the case, when
> Keycloak
> > uses Wildfly ?
> >
> > Thank you. With regards V. Havlik.
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>