<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
By "pretty sure" I mean that replication is working perfectly fine
for similar cache containers.<br>
The default configuration for the session replication mode in
Wildfly 10 is asynchronous so I guess the reason for my problems is
the replication lag then.<br>
<br>
I will try it out then and let you know for sure, but as far as I
understand the problem, the only possible solutions are to either
configure synchronous session replication or asynchronous session
replication in combination with sticky sessions. Hopefully you can
add a warning to the user manual so that other users don't run into
the same problems.<br>
<br>
<br>
<div class="moz-cite-prefix">Am 25.01.2016 um 21:58 schrieb Bill
Burke:<br>
</div>
<blockquote cite="mid:56A68C7E.4080508@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
What do you mean by you're "pretty sure clustering/session
replication is configured correctly". Either its working or it
isn't. Have you tested a simple application WITHOUT keycloak and
with Round Robin to determine if replication is set? Because
from what you are describing and what Stian said to you over and
over again is that it does not look like HTTP session replication
is working for you. Keycloak client adapter stores that you are
authenticated within the HttpSession. It is possible that session
replication is lagging I think...only if you have async
replication turned on. I don't know what the default is in
Wildfly 10.<br>
<br>
Also, a forbidden exception might mean that your web.xml requires
a role set for the user for the URL you are accessing and the user
does not have that role assigned to them.<br>
<br>
On 1/25/2016 2:33 PM, Christian Beikov wrote:<br>
<blockquote cite="mid:56A6788E.5030408@gmail.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
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
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide"><a class="moz-txt-link-freetext" href="https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide">https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide</a></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<br>
<br>
<div class="moz-cite-prefix">Am 25.01.2016 um 19:04 schrieb
Stian Thorgersen:<br>
</div>
<blockquote
cite="mid:CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com"
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
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:christian.beikov@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:christian.beikov@gmail.com">christian.beikov@gmail.com</a></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 class="h5"><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
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:christian.beikov@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:christian.beikov@gmail.com">christian.beikov@gmail.com</a></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
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:christian.beikov@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:christian.beikov@gmail.com">christian.beikov@gmail.com</a></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
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html"><a class="moz-txt-link-freetext" href="http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html">http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html</a></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
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:christian.beikov@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:christian.beikov@gmail.com">christian.beikov@gmail.com</a></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
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:keycloak-dev@lists.jboss.org"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></a><br>
<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>