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@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@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@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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev








_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev



_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev