<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 January 2016 at 20:33, Christian Beikov <span dir="ltr"><<a href="mailto:christian.beikov@gmail.com" target="_blank">christian.beikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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.<br>
Either I don't understand something about session replication or I
require a configuration that you don't mention anywhere.<br>
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:
<a href="https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide" target="_blank">https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide</a><br>
<br>
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.<br>
<br>
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?<br>
<br>
Regards,<br>
Christian<div><div class="h5"><br>
<br>
<div>Am 25.01.2016 um 19:04 schrieb Stian
Thorgersen:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Try google for wildfly replicate http sessions</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 25 January 2016 at 15:53, Christian
Beikov <span dir="ltr"><<a href="mailto:christian.beikov@gmail.com" target="_blank">christian.beikov@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I just wrote that I
configured clustering for my application just like in the
standlone-ha.xml of my Wildfly 10 CR4.<br>
I configured the jgroups subsystem and the distributed
caches for web sessions as it is done in standalone-ha.xml
of Wildfly.<br>
If there is anything else that should be configured, can
you please point me to that configuration option?<br>
<br>
Regards,<br>
Christian
<div>
<div><br>
<br>
<div>Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:<br>
</div>
<blockquote type="cite">
<div dir="ltr">HTTP session replicate is not enabled
by default. You need to enable it for your
application.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 25 January 2016 at
14:39, Christian Beikov <span dir="ltr"><<a href="mailto:christian.beikov@gmail.com" target="_blank"></a><a href="mailto:christian.beikov@gmail.com" target="_blank">christian.beikov@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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.<br>
<br>
Regards,<br>
Christian
<div>
<div><br>
<br>
<div>Am 25.01.2016 um 14:20 schrieb
Stian Thorgersen:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Your issue doesn't have
anything to do with the Keycloak
server side user sessions, they
don't require sticky sessions.
<div><br>
</div>
<div>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.
<div><br>
<div><br>
<div class="gmail_extra">
<div class="gmail_quote">On
25 January 2016 at 14:05,
Christian Beikov <span dir="ltr"><<a href="mailto:christian.beikov@gmail.com" target="_blank"></a><a href="mailto:christian.beikov@gmail.com" target="_blank">christian.beikov@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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?</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Regards,<br>
Christian
<div>
<div><br>
<br>
<div>Am 25.01.2016
um 08:58 schrieb
Stian
Thorgersen:<br>
</div>
<blockquote type="cite">
<div dir="ltr">By
default the
adapters will
require sticky
sessions,
please refer
to <a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html" target="_blank"></a><a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html</a>
for more
information</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
22 January
2016 at 12:48,
Christian
Beikov <span dir="ltr"><<a href="mailto:christian.beikov@gmail.com" target="_blank"></a><a href="mailto:christian.beikov@gmail.com" target="_blank">christian.beikov@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I am running
some tests
with my
application
cluster being
secured by a<br>
single
keycloak
server
instance and I
encountered
problems with
the adapter.<br>
<br>
My application
cluster
contains 2
nodes and is
load balanced
by nginx.<br>
For testing
purposes, I
enabled round
robin load
balancing
which is<br>
probably the
"cause" for my
issues.<br>
<br>
When I access
a secured
page, I get
redirected to
keycloak and<br>
everything is
fine. When I
then login,
and keycloak
redirects me
back to<br>
the
application, I
get to a
different
application
cluster node
because<br>
of round
robin. On that
node,
apparently the
initial
information of
the<br>
client session
is not
available and
I get
redirected to
keycloak login<br>
page again.
Then keycloak
redirects me
back to the
application,
this<br>
time to the
original node,
and says that
access is
forbidden.<br>
<br>
I suppose the
web session
caches are not
in sync but I
just used the<br>
default cache
containers as
they are
defined in
standalone-ha.xml
of my<br>
Wildlfy 10
CR4.
Clustering
with jgroups
works, as I
use other<br>
distributed
caches too
which work
just fine.<br>
<br>
We are using
Keycloak
1.8.0.CR2 on a
Wildfly 10 CR4<br>
<br>
Regards,<br>
Christian<br>
_______________________________________________<br>
keycloak-dev
mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank"></a><a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank"></a><a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>