On Mon, Feb 11, 2019 at 10:53 AM Vaclav Havlik <Johny.Dee(a)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/...
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-cont...
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(a)redhat.com>
Komu: Vaclav Havlik <Johny.Dee(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user