10 a.m.
Hey guys,
During our weekly sync meeting, Stian asked me to look into different
options for clustering in Keycloak server. This topic has quite hot with
the context of our Docker image (see the proposed community contributions
[1][2][3]). Since we are based on WF 13, which uses JGroups 4.0.11 and has
KUBE_PING in its modules, we have a couple of options how to do it.
Before discussing different implementations, let me quickly go through the
requirements:
- We need a configuration stack that works for on-prem and cloud
deployments with OpenShift as our primary target.
- The configuration should be automatic (if it's possible). E.g. if we
discover that Keycloak is running in the container, we should use proper
discovery protocol.
- There needs to be a way to override the discovery protocol manually.
With those requirements in mind, we have a couple of implementation options
on the table:
1. Add more stacks to the configuration, e.g. openshift, azure or gcp. Then
we use the standard `-Djboss.default.jgroups.stack=<stack>` configuration
switch.
2. Provide more standalone-*.xml configuration files, e.g.
standalone-ha.xml (for on-prem) or standalone-cloud.xml.
3. Add protocols dynamically using CLI. A similar approach to what we did
for the Data Grid Cache Service [4].
4. Use MULTI_PING protocols [5][6], with multiple discovery protocols on
the same stack. This will include MPING (for multicasting), KUBE_PING (if
we can access Kubernetes API), DNS_PING (if Pods are governed by a Service).
Option #1 and #2 is somewhat similar to what we did for Infinispan [7]. It
works quite well but the configuration grows quite quickly and most of the
protocols (apart from discovery) are duplicated. On the other hand, having
separate configuration pieces for each use case is very flexible. Having in
mind that AWS cuts TCP connections, using FD_SOCK might lead to false
suspicions but on GCP for the instance, FD_SOCK works quite nicely. The CLI
option (#3), is also very flexible and probably should be implemented only
in our Docker image. This somehow follows the convention we already started
with different CLI files for different DBs [8]. Option #4 is brand new
(implemented in JGroups 4.0.8; we have 4.0.11 as you probably recall). It
has been specifically designed for this kind of use cases where we want to
gather discovery data from multiple places. Using this way, we should end
up with two stacks in standalone-ha.xml file - UDP and TCP.
I honestly need to say, that my heart goes for options #4. However, as far
as I know it hasn't been battle tested and we might get some surprises. All
other options are not as elegant as option #4 but they are used somewhere
in other projects. They are much safer options but they will add some
maintenance burden on our shoulders.
What would you suggest guys? What do you think about all this? @Rado,
@Paul, @Tristan - Do you have any plans regarding this piece in Wildfly or
Infinispan?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/96
[2] https://github.com/jboss-dockerfiles/keycloak/pull/100
[3] https://github.com/jboss-dockerfiles/keycloak/pull/116
[4]
https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
[5] http://www.jgroups.org/manual4/index.html#_multi_ping
[6] https://issues.jboss.org/browse/JGRP-2224
[7]
https://github.com/infinispan/infinispan/tree/master/server/integration/j...
[8]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
11:17 a.m.
Hi Sebastian! :)
What about just using JDBC_PING as a default? It works in any environment, it does not add
an additional dependency as Keycloak does not do much without DB anyways.
The only problem we are currently having is that the graceful shutdown does not work since
the dependency of the Jgroups subsystem to the DB is not identified correctly.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On
Behalf Of Sebastian Laskawiec
Sent: Mittwoch, 12. September 2018 10:00
To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Cc: Bela Ban <bban(a)redhat.com>; Radoslav Husar <rhusar(a)redhat.com>; Tarrant,
Tristan <ttarrant(a)redhat.com>; Paul Ferraro <paul.ferraro(a)redhat.com>
Subject: [keycloak-dev] Clustering configuration
Hey guys,
During our weekly sync meeting, Stian asked me to look into different options for
clustering in Keycloak server. This topic has quite hot with the context of our Docker
image (see the proposed community contributions [1][2][3]). Since we are based on WF 13,
which uses JGroups 4.0.11 and has KUBE_PING in its modules, we have a couple of options
how to do it.
Before discussing different implementations, let me quickly go through the
requirements:
- We need a configuration stack that works for on-prem and cloud deployments with
OpenShift as our primary target.
- The configuration should be automatic (if it's possible). E.g. if we discover that
Keycloak is running in the container, we should use proper discovery protocol.
- There needs to be a way to override the discovery protocol manually.
With those requirements in mind, we have a couple of implementation options on the table:
1. Add more stacks to the configuration, e.g. openshift, azure or gcp. Then we use the
standard `-Djboss.default.jgroups.stack=<stack>` configuration switch.
2. Provide more standalone-*.xml configuration files, e.g.
standalone-ha.xml (for on-prem) or standalone-cloud.xml.
3. Add protocols dynamically using CLI. A similar approach to what we did for the Data
Grid Cache Service [4].
4. Use MULTI_PING protocols [5][6], with multiple discovery protocols on the same stack.
This will include MPING (for multicasting), KUBE_PING (if we can access Kubernetes API),
DNS_PING (if Pods are governed by a Service).
Option #1 and #2 is somewhat similar to what we did for Infinispan [7]. It works quite
well but the configuration grows quite quickly and most of the protocols (apart from
discovery) are duplicated. On the other hand, having separate configuration pieces for
each use case is very flexible. Having in mind that AWS cuts TCP connections, using
FD_SOCK might lead to false suspicions but on GCP for the instance, FD_SOCK works quite
nicely. The CLI option (#3), is also very flexible and probably should be implemented only
in our Docker image. This somehow follows the convention we already started with different
CLI files for different DBs [8]. Option #4 is brand new (implemented in JGroups 4.0.8; we
have 4.0.11 as you probably recall). It has been specifically designed for this kind of
use cases where we want to gather discovery data from multiple places. Using this way, we
should end up with two stacks in standalone-ha.xml file - UDP and TCP.
I honestly need to say, that my heart goes for options #4. However, as far as I know it
hasn't been battle tested and we might get some surprises. All other options are not
as elegant as option #4 but they are used somewhere in other projects. They are much safer
options but they will add some maintenance burden on our shoulders.
What would you suggest guys? What do you think about all this? @Rado, @Paul, @Tristan - Do
you have any plans regarding this piece in Wildfly or Infinispan?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/96
[2] https://github.com/jboss-dockerfiles/keycloak/pull/100
[3] https://github.com/jboss-dockerfiles/keycloak/pull/116
[4]
https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
[5] http://www.jgroups.org/manual4/index.html#_multi_ping
[6] https://issues.jboss.org/browse/JGRP-2224
[7]
https://github.com/infinispan/infinispan/tree/master/server/integration/j...
[8]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:41 a.m.
Hi all,
while you are mentioning JDBC_PING it seems that the configuration somewhat
changed between 4.2.1 and 4.4.0 probably due to the wildfly /infinispan
upgrade. The keycloak Helm chart for Kubernetes just stumbled upon this
while trying to upgrade to 4.4.0.Final.
See:
https://github.com/helm/charts/pull/7650#issuecomment-420174274
BTW. another configuration option would be to use TCP unicast with a set of
initial hosts for discovery. This is useful in scenarios where multiple
network-segments are involved that don't support UDP multicast and
jdbc_ping cannot be used (... for what ever reason).
Cheers,
Thomas
Schuster Sebastian (INST-CSS/BSV-OS) <Sebastian.Schuster(a)bosch-si.com>
schrieb am Mi., 12. Sep. 2018, 11:25:
Hi Sebastian! :)
What about just using JDBC_PING as a default? It works in any environment,
it does not add an additional dependency as Keycloak does not do much
without DB anyways.
The only problem we are currently having is that the graceful shutdown
does not work since the dependency of the Jgroups subsystem to the DB is
not identified correctly.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Sebastian Laskawiec
Sent: Mittwoch, 12. September 2018 10:00
To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Cc: Bela Ban <bban(a)redhat.com>; Radoslav Husar <rhusar(a)redhat.com>;
Tarrant, Tristan <ttarrant(a)redhat.com>; Paul Ferraro <
paul.ferraro(a)redhat.com>
Subject: [keycloak-dev] Clustering configuration
Hey guys,
During our weekly sync meeting, Stian asked me to look into different
options for clustering in Keycloak server. This topic has quite hot with
the context of our Docker image (see the proposed community contributions
[1][2][3]). Since we are based on WF 13, which uses JGroups 4.0.11 and has
KUBE_PING in its modules, we have a couple of options how to do it.
Before discussing different implementations, let me quickly go through the
requirements:
- We need a configuration stack that works for on-prem and cloud
deployments with OpenShift as our primary target.
- The configuration should be automatic (if it's possible). E.g. if we
discover that Keycloak is running in the container, we should use proper
discovery protocol.
- There needs to be a way to override the discovery protocol manually.
With those requirements in mind, we have a couple of implementation
options on the table:
1. Add more stacks to the configuration, e.g. openshift, azure or gcp.
Then we use the standard `-Djboss.default.jgroups.stack=<stack>`
configuration switch.
2. Provide more standalone-*.xml configuration files, e.g.
standalone-ha.xml (for on-prem) or standalone-cloud.xml.
3. Add protocols dynamically using CLI. A similar approach to what we did
for the Data Grid Cache Service [4].
4. Use MULTI_PING protocols [5][6], with multiple discovery protocols on
the same stack. This will include MPING (for multicasting), KUBE_PING (if
we can access Kubernetes API), DNS_PING (if Pods are governed by a Service).
Option #1 and #2 is somewhat similar to what we did for Infinispan [7]. It
works quite well but the configuration grows quite quickly and most of the
protocols (apart from discovery) are duplicated. On the other hand, having
separate configuration pieces for each use case is very flexible. Having in
mind that AWS cuts TCP connections, using FD_SOCK might lead to false
suspicions but on GCP for the instance, FD_SOCK works quite nicely. The CLI
option (#3), is also very flexible and probably should be implemented only
in our Docker image. This somehow follows the convention we already started
with different CLI files for different DBs [8]. Option #4 is brand new
(implemented in JGroups 4.0.8; we have 4.0.11 as you probably recall). It
has been specifically designed for this kind of use cases where we want to
gather discovery data from multiple places. Using this way, we should end
up with two stacks in standalone-ha.xml file - UDP and TCP.
I honestly need to say, that my heart goes for options #4. However, as far
as I know it hasn't been battle tested and we might get some surprises. All
other options are not as elegant as option #4 but they are used somewhere
in other projects. They are much safer options but they will add some
maintenance burden on our shoulders.
What would you suggest guys? What do you think about all this? @Rado,
@Paul, @Tristan - Do you have any plans regarding this piece in Wildfly or
Infinispan?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/96
[2] https://github.com/jboss-dockerfiles/keycloak/pull/100
[3] https://github.com/jboss-dockerfiles/keycloak/pull/116
[4]
https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
[5] http://www.jgroups.org/manual4/index.html#_multi_ping
[6] https://issues.jboss.org/browse/JGRP-2224
[7]
https://github.com/infinispan/infinispan/tree/master/server/integration/j...
[8]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:56 a.m.
Guess what, our JDBC_PING configuration not working with 4.4.0.Final is what I am
currently working on.
Thanks Thomas!
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
From: Thomas Darimont <thomas.darimont(a)googlemail.com>
Sent: Mittwoch, 12. September 2018 11:41
To: Schuster Sebastian (INST-CSS/BSV-OS) <Sebastian.Schuster(a)bosch-si.com>
Cc: Sebastian Laskawiec <slaskawi(a)redhat.com>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>; Bela Ban <bban(a)redhat.com>; Radoslav Husar
<rhusar(a)redhat.com>; Tarrant, Tristan <ttarrant(a)redhat.com>; Paul Ferraro
<paul.ferraro(a)redhat.com>
Subject: Re: [keycloak-dev] Clustering configuration
Hi all,
while you are mentioning JDBC_PING it seems that the configuration somewhat changed
between 4.2.1 and 4.4.0 probably due to the wildfly /infinispan upgrade. The keycloak Helm
chart for Kubernetes just stumbled upon this while trying to upgrade to 4.4.0.Final.
See:
https://github.com/helm/charts/pull/7650#issuecomment-420174274
BTW. another configuration option would be to use TCP unicast with a set of initial hosts
for discovery. This is useful in scenarios where multiple network-segments are involved
that don't support UDP multicast and jdbc_ping cannot be used (... for what ever
reason).
Cheers,
Thomas
Schuster Sebastian (INST-CSS/BSV-OS)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
schrieb am Mi., 12. Sep. 2018, 11:25:
Hi Sebastian! :)
What about just using JDBC_PING as a default? It works in any environment, it does not add
an additional dependency as Keycloak does not do much without DB anyways.
The only problem we are currently having is that the graceful shutdown does not work since
the dependency of the Jgroups subsystem to the DB is not identified correctly.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From:
keycloak-dev-bounces@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>
<keycloak-dev-bounces@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>>
On Behalf Of Sebastian Laskawiec
Sent: Mittwoch, 12. September 2018 10:00
To: keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Cc: Bela Ban <bban@redhat.com<mailto:bban@redhat.com>>; Radoslav Husar
<rhusar@redhat.com<mailto:rhusar@redhat.com>>; Tarrant, Tristan
<ttarrant@redhat.com<mailto:ttarrant@redhat.com>>; Paul Ferraro
<paul.ferraro@redhat.com<mailto:paul.ferraro@redhat.com>>
Subject: [keycloak-dev] Clustering configuration
Hey guys,
During our weekly sync meeting, Stian asked me to look into different options for
clustering in Keycloak server. This topic has quite hot with the context of our Docker
image (see the proposed community contributions [1][2][3]). Since we are based on WF 13,
which uses JGroups 4.0.11 and has KUBE_PING in its modules, we have a couple of options
how to do it.
Before discussing different implementations, let me quickly go through the
requirements:
- We need a configuration stack that works for on-prem and cloud deployments with
OpenShift as our primary target.
- The configuration should be automatic (if it's possible). E.g. if we discover that
Keycloak is running in the container, we should use proper discovery protocol.
- There needs to be a way to override the discovery protocol manually.
With those requirements in mind, we have a couple of implementation options on the
table:
1. Add more stacks to the configuration, e.g. openshift, azure or gcp. Then we use the
standard `-Djboss.default.jgroups.stack=<stack>` configuration switch.
2. Provide more standalone-*.xml configuration files, e.g.
standalone-ha.xml (for on-prem) or standalone-cloud.xml.
3. Add protocols dynamically using CLI. A similar approach to what we did for the Data
Grid Cache Service [4].
4. Use MULTI_PING protocols [5][6], with multiple discovery protocols on the same stack.
This will include MPING (for multicasting), KUBE_PING (if we can access Kubernetes API),
DNS_PING (if Pods are governed by a Service).
Option #1 and #2 is somewhat similar to what we did for Infinispan [7]. It works quite
well but the configuration grows quite quickly and most of the protocols (apart from
discovery) are duplicated. On the other hand, having separate configuration pieces for
each use case is very flexible. Having in mind that AWS cuts TCP connections, using
FD_SOCK might lead to false suspicions but on GCP for the instance, FD_SOCK works quite
nicely. The CLI option (#3), is also very flexible and probably should be implemented only
in our Docker image. This somehow follows the convention we already started with different
CLI files for different DBs [8]. Option #4 is brand new (implemented in JGroups 4.0.8; we
have 4.0.11 as you probably recall). It has been specifically designed for this kind of
use cases where we want to gather discovery data from multiple places. Using this way, we
should end up with two stacks in standalone-ha.xml file - UDP and TCP.
I honestly need to say, that my heart goes for options #4. However, as far as I know it
hasn't been battle tested and we might get some surprises. All other options are not
as elegant as option #4 but they are used somewhere in other projects. They are much safer
options but they will add some maintenance burden on our shoulders.
What would you suggest guys? What do you think about all this? @Rado, @Paul, @Tristan - Do
you have any plans regarding this piece in Wildfly or Infinispan?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/96
[2] https://github.com/jboss-dockerfiles/keycloak/pull/100
[3] https://github.com/jboss-dockerfiles/keycloak/pull/116
[4]
https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
[5] http://www.jgroups.org/manual4/index.html#_multi_ping
[6] https://issues.jboss.org/browse/JGRP-2224
[7]
https://github.com/infinispan/infinispan/tree/master/server/integration/j...
[8]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:17 p.m.
Hi all,
Le Mercredi, Septembre 12, 2018 11:17 CEST, "Schuster Sebastian
(INST-CSS/BSV-OS)" <Sebastian.Schuster(a)bosch-si.com> a écrit:
Hi Sebastian! :)
What about just using JDBC_PING as a default? It works in any environment, it does not
add an additional dependency as Keycloak does not do much without DB anyways.
+1 for JDBC_PING as an option. I am using Mesos at the moment, and JDBC_PING is the only
option for me. At minimal, documenting how to add the configuration in a custom keycloak
docker image would be great.
The only problem we are currently having is that the graceful
shutdown does not work since the dependency of the Jgroups subsystem to the DB is not
identified correctly.
Best regards,
Sebastian
1:33 p.m.
Hi Sebastian,
Le Mercredi, Septembre 12, 2018 11:56 CEST, "Schuster Sebastian
(INST-CSS/BSV-OS)" <Sebastian.Schuster(a)bosch-si.com> a écrit:
Guess what, our JDBC_PING configuration not working with 4.4.0.Final
is what I am currently working on.
If it helps, I had some difficulties configuring JDBC_PING on keycloak 4.4.0.Final.
My final working configuration is :
<subsystem xmlns="urn:jboss:domain:jgroups:6.0">
<channels default="ee">
<channel name="ee" stack="tcpping"/>
</channels>
<stacks>
<stack name="tcpping">
<transport type="TCP"
socket-binding="jgroups-tcp">
<property name="external_addr">
${jgroups.bind.address:127.0.0.1}
</property>
<property name="bind_addr">
${jgroups.bind_addr:SITE_LOCAL}
</property>
</transport>
<jdbc-protocol type="JDBC_PING"
data-source="KeycloakDS">
<property name="initialize_sql">
CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr varchar(200)
NOT NULL,bind_addr varchar(200) NOT NULL,created timestamp NOT NULL,cluster_name
varchar(200) NOT NULL,ping_data BYTEA,constraint PK_JGROUPSPING PRIMARY KEY (own_addr,
cluster_name))
</property>
<property name="insert_single_sql">
INSERT INTO JGROUPSPING (own_addr, bind_addr, created,
cluster_name, ping_data) values (?,'${jgroups.bind.address:127.0.0.1}',NOW(), ?,
?)
</property>
<property name="delete_single_sql">
DELETE FROM JGROUPSPING WHERE own_addr=? AND cluster_name=?
</property>
<property name="select_all_pingdata_sql">
SELECT ping_data FROM JGROUPSPING WHERE cluster_name=?;
</property>
</jdbc-protocol>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd">
<property name="external_addr">
${jgroups.bind.address:127.0.0.1}
</property>
</protocol>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
I do it in my own docker image where I change the configuration with jboss-cli (as in the
officilal) with this file :
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:remove
/subsystem=infinispan/cache-container=keycloak/replicated-cache=sessions:add()
/subsystem=infinispan/cache-container=keycloak/replicated-cache=sessions:write-attribute(name="mode",value="SYNC")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:add(mode="SYNC",owners="2")
/subsystem=jgroups/stack=tcpping:add()
/subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp)
/subsystem=jgroups/stack=tcpping/transport=TCP/property=external_addr:add(value=${jgroups.bind.address:127.0.0.1})
/subsystem=jgroups/stack=tcpping/transport=TCP/property=bind_addr:add(value=${jgroups.bind_addr:SITE_LOCAL})
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING:add(data-source="KeycloakDS",
properties=[initialize_sql="CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr
varchar(200) NOT NULL,bind_addr varchar(200) NOT NULL,created timestamp NOT
NULL,cluster_name varchar(200) NOT NULL,ping_data BYTEA,constraint PK_JGROUPSPING PRIMARY
KEY (own_addr, cluster_name))",insert_single_sql="INSERT INTO JGROUPSPING
(own_addr, bind_addr, created, cluster_name, ping_data) values
(?,'${jgroups.bind.address:127.0.0.1}',NOW(), ?,
?)",delete_single_sql="DELETE FROM JGROUPSPING WHERE own_addr=? AND
cluster_name=?",select_all_pingdata_sql="SELECT ping_data FROM JGROUPSPING WHERE
cluster_name=?;"])
/subsystem=jgroups/stack=tcpping/protocol=MERGE3:add()
/subsystem=jgroups/stack=tcpping:add-protocol(type="FD_SOCK",socket-binding="jgroups-tcp-fd")
/subsystem=jgroups/stack=tcpping/protocol=FD_SOCK/property=external_addr:add(value=${jgroups.bind.address:127.0.0.1})
/subsystem=jgroups/stack=tcpping/protocol=FD:add()
/subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add()
/subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add()
/subsystem=jgroups/stack=tcpping/protocol=MFC:add()
/subsystem=jgroups/stack=tcpping/protocol=FRAG2:add()
/subsystem=jgroups/channel=ee:remove
/subsystem=jgroups/channel=ee:add(stack=tcpping)
/subsystem=jgroups:write-attribute(name=default-channel, value=ee)
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp:write-attribute(name="interface",value="private")
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:add()
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:write-attribute(name="interface",value="private")
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:write-attribute(name="port",value="57600")
/subsystem=jgroups/stack=tcp:remove
/subsystem=jgroups/stack=udp:remove
I am not sure all is good in this but it works (in my environment :) ).
(the difficulties I had was that if the cli file is like :
...
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING:add(data-source="KeycloakDS")
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING/property=datasource_jndi_name:add(value=java:jboss/datasources/KeycloakDS)
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING/property=otherproperty:add(value=other_value)
...
the configuration in xml is :
<protocol type="org.apache.jgroups.JDBC_PING" >
Which doesn't work (don't know why). There is not a lot of documentation on this,
so I'm listening to all suggestions.
Cheers,
Cédric Couralet
10:16 a.m.
On Wed, 12 Sep 2018 at 10:09, Sebastian Laskawiec <slaskawi(a)redhat.com>
wrote:
Hey guys,
During our weekly sync meeting, Stian asked me to look into different
options for clustering in Keycloak server. This topic has quite hot with
the context of our Docker image (see the proposed community contributions
[1][2][3]). Since we are based on WF 13, which uses JGroups 4.0.11 and has
KUBE_PING in its modules, we have a couple of options how to do it.
Before discussing different implementations, let me quickly go through the
requirements:
- We need a configuration stack that works for on-prem and cloud
deployments with OpenShift as our primary target.
OpenShift is not our primary target in community. We should have support
for standalone Docker, Kubernetes and OpenShift. For GCP and EC2 we should
have something that works, but will probably not be able to test this
ourselves.
- The configuration should be automatic (if it's possible). E.g.
if we
discover that Keycloak is running in the container, we should use proper
discovery protocol.
- There needs to be a way to override the discovery protocol manually.
With those requirements in mind, we have a couple of implementation options
on the table:
1. Add more stacks to the configuration, e.g. openshift, azure or gcp. Then
we use the standard `-Djboss.default.jgroups.stack=<stack>` configuration
switch.
2. Provide more standalone-*.xml configuration files, e.g.
standalone-ha.xml (for on-prem) or standalone-cloud.xml.
3. Add protocols dynamically using CLI. A similar approach to what we did
for the Data Grid Cache Service [4].
4. Use MULTI_PING protocols [5][6], with multiple discovery protocols on
the same stack. This will include MPING (for multicasting), KUBE_PING (if
we can access Kubernetes API), DNS_PING (if Pods are governed by a
Service).
All config should be done through CLI commands. Did you look at how we do
this for DBs? The standalone-*.xml file is modified at runtime to switch
between selected DBs.
To keep things consistent your options are:
* A single CLI script that configures something that works in all scenarios
* A single CLI script that configures alternatives stacks that are enabled
depending on some environment variables
* The same approach as done for DBs where we have different directories for
each DB with different CLI scripts for each DB. This DB specific CLI is
then executed at startup time to re-configure standalone.xml
Anything else will be a maintenance headache.
Option #1 and #2 is somewhat similar to what we did for Infinispan [7]. It
works quite well but the configuration grows quite quickly and most of the
protocols (apart from discovery) are duplicated. On the other hand, having
separate configuration pieces for each use case is very flexible. Having in
mind that AWS cuts TCP connections, using FD_SOCK might lead to false
suspicions but on GCP for the instance, FD_SOCK works quite nicely. The CLI
option (#3), is also very flexible and probably should be implemented only
in our Docker image. This somehow follows the convention we already started
with different CLI files for different DBs [8]. Option #4 is brand new
(implemented in JGroups 4.0.8; we have 4.0.11 as you probably recall). It
has been specifically designed for this kind of use cases where we want to
gather discovery data from multiple places. Using this way, we should end
up with two stacks in standalone-ha.xml file - UDP and TCP.
I honestly need to say, that my heart goes for options #4. However, as far
as I know it hasn't been battle tested and we might get some surprises. All
other options are not as elegant as option #4 but they are used somewhere
in other projects. They are much safer options but they will add some
maintenance burden on our shoulders.
I do like the idea of option #4, but worried about it not working and
causing strange behaviour.
What would you suggest guys? What do you think about all this? @Rado,
@Paul, @Tristan - Do you have any plans regarding this piece in Wildfly or
Infinispan?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/96
[2] https://github.com/jboss-dockerfiles/keycloak/pull/100
[3] https://github.com/jboss-dockerfiles/keycloak/pull/116
[4]
https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
[5] http://www.jgroups.org/manual4/index.html#_multi_ping
[6] https://issues.jboss.org/browse/JGRP-2224
[7]
https://github.com/infinispan/infinispan/tree/master/server/integration/j...
[8]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:22 p.m.
Hi Cédric,
Thanks for your help. I tested your configuration and it seems to work but the effects are
still kind of unexpected.
It looks like the cluster is formed correctly. But the way JDBC_PING itself works is
completely different from before. In the past, every node removed and readded itself to
the JGROUPSPING table every few seconds. Now it looks like only the master node updates
the JGROUPSPING table and only when it detects a change. It also always inserts its own
address for every node. That makes the JGROUPSPING table look kind of strange as it does
not contain the correct addresses for all the nodes. I have not found documentation for
such a big change so I am not sure this is all intended...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: cedric(a)couralet.eu <cedric(a)couralet.eu>
Sent: Mittwoch, 12. September 2018 13:33
To: Schuster Sebastian (INST-CSS/BSV-OS) <Sebastian.Schuster(a)bosch-si.com>
Cc: Thomas Darimont <thomas.darimont(a)googlemail.com>; Radoslav Husar
<rhusar(a)redhat.com>; Bela Ban <bban(a)redhat.com>; Paul Ferraro
<paul.ferraro(a)redhat.com>; keycloak-dev <keycloak-dev(a)lists.jboss.org>;
Tarrant, Tristan <ttarrant(a)redhat.com>
Subject: Re: [keycloak-dev] Clustering configuration
Hi Sebastian,
Le Mercredi, Septembre 12, 2018 11:56 CEST, "Schuster Sebastian
(INST-CSS/BSV-OS)" <Sebastian.Schuster(a)bosch-si.com> a écrit:
Guess what, our JDBC_PING configuration not working with 4.4.0.Final
is what I am currently working on.
If it helps, I had some difficulties configuring JDBC_PING on keycloak 4.4.0.Final.
My final working configuration is :
<subsystem xmlns="urn:jboss:domain:jgroups:6.0">
<channels default="ee">
<channel name="ee" stack="tcpping"/>
</channels>
<stacks>
<stack name="tcpping">
<transport type="TCP"
socket-binding="jgroups-tcp">
<property name="external_addr">
${jgroups.bind.address:127.0.0.1}
</property>
<property name="bind_addr">
${jgroups.bind_addr:SITE_LOCAL}
</property>
</transport>
<jdbc-protocol type="JDBC_PING"
data-source="KeycloakDS">
<property name="initialize_sql">
CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr varchar(200)
NOT NULL,bind_addr varchar(200) NOT NULL,created timestamp NOT NULL,cluster_name
varchar(200) NOT NULL,ping_data BYTEA,constraint PK_JGROUPSPING PRIMARY KEY (own_addr,
cluster_name))
</property>
<property name="insert_single_sql">
INSERT INTO JGROUPSPING (own_addr, bind_addr, created,
cluster_name, ping_data) values (?,'${jgroups.bind.address:127.0.0.1}',NOW(), ?,
?)
</property>
<property name="delete_single_sql">
DELETE FROM JGROUPSPING WHERE own_addr=? AND cluster_name=?
</property>
<property name="select_all_pingdata_sql">
SELECT ping_data FROM JGROUPSPING WHERE cluster_name=?;
</property>
</jdbc-protocol>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd">
<property name="external_addr">
${jgroups.bind.address:127.0.0.1}
</property>
</protocol>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
I do it in my own docker image where I change the configuration with jboss-cli (as in the
officilal) with this file :
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:remove
/subsystem=infinispan/cache-container=keycloak/replicated-cache=sessions:add()
/subsystem=infinispan/cache-container=keycloak/replicated-cache=sessions:write-attribute(name="mode",value="SYNC")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:add(mode="SYNC",owners="2")
/subsystem=jgroups/stack=tcpping:add()
/subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp)
/subsystem=jgroups/stack=tcpping/transport=TCP/property=external_addr:add(value=${jgroups.bind.address:127.0.0.1})
/subsystem=jgroups/stack=tcpping/transport=TCP/property=bind_addr:add(value=${jgroups.bind_addr:SITE_LOCAL})
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING:add(data-source="KeycloakDS",
properties=[initialize_sql="CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr
varchar(200) NOT NULL,bind_addr varchar(200) NOT NULL,created timestamp NOT
NULL,cluster_name varchar(200) NOT NULL,ping_data BYTEA,constraint PK_JGROUPSPING PRIMARY
KEY (own_addr, cluster_name))",insert_single_sql="INSERT INTO JGROUPSPING
(own_addr, bind_addr, created, cluster_name, ping_data) values
(?,'${jgroups.bind.address:127.0.0.1}',NOW(), ?,
?)",delete_single_sql="DELETE FROM JGROUPSPING WHERE own_addr=? AND
cluster_name=?",select_all_pingdata_sql="SELECT ping_data FROM JGROUPSPING WHERE
cluster_name=?;"])
/subsystem=jgroups/stack=tcpping/protocol=MERGE3:add()
/subsystem=jgroups/stack=tcpping:add-protocol(type="FD_SOCK",socket-binding="jgroups-tcp-fd")
/subsystem=jgroups/stack=tcpping/protocol=FD_SOCK/property=external_addr:add(value=${jgroups.bind.address:127.0.0.1})
/subsystem=jgroups/stack=tcpping/protocol=FD:add()
/subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add()
/subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add()
/subsystem=jgroups/stack=tcpping/protocol=MFC:add()
/subsystem=jgroups/stack=tcpping/protocol=FRAG2:add()
/subsystem=jgroups/channel=ee:remove
/subsystem=jgroups/channel=ee:add(stack=tcpping)
/subsystem=jgroups:write-attribute(name=default-channel, value=ee)
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp:write-attribute(name="interface",value="private")
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:add()
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:write-attribute(name="interface",value="private")
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:write-attribute(name="port",value="57600")
/subsystem=jgroups/stack=tcp:remove
/subsystem=jgroups/stack=udp:remove
I am not sure all is good in this but it works (in my environment :) ).
(the difficulties I had was that if the cli file is like :
...
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING:add(data-source="KeycloakDS")
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING/property=datasource_jndi_name:add(value=java:jboss/datasources/KeycloakDS)
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING/property=otherproperty:add(value=other_value)
...
the configuration in xml is :
<protocol type="org.apache.jgroups.JDBC_PING" >
Which doesn't work (don't know why). There is not a lot of documentation on this,
so I'm listening to all suggestions.
Cheers,
Cédric Couralet
5:30 p.m.
Btw. the fact that there is only one IP address in JGROUPSPING is of course due to the
configured insert_single_sql statement always taking the address of the local node. This
will always be the master's address if it is the only one writing to the table...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: cedric(a)couralet.eu <cedric(a)couralet.eu>
Sent: Mittwoch, 12. September 2018 13:33
To: Schuster Sebastian (INST-CSS/BSV-OS) <Sebastian.Schuster(a)bosch-si.com>
Cc: Thomas Darimont <thomas.darimont(a)googlemail.com>; Radoslav Husar
<rhusar(a)redhat.com>; Bela Ban <bban(a)redhat.com>; Paul Ferraro
<paul.ferraro(a)redhat.com>; keycloak-dev <keycloak-dev(a)lists.jboss.org>;
Tarrant, Tristan <ttarrant(a)redhat.com>
Subject: Re: [keycloak-dev] Clustering configuration
Hi Sebastian,
Le Mercredi, Septembre 12, 2018 11:56 CEST, "Schuster Sebastian
(INST-CSS/BSV-OS)" <Sebastian.Schuster(a)bosch-si.com> a écrit:
Guess what, our JDBC_PING configuration not working with 4.4.0.Final
is what I am currently working on.
If it helps, I had some difficulties configuring JDBC_PING on keycloak 4.4.0.Final.
My final working configuration is :
<subsystem xmlns="urn:jboss:domain:jgroups:6.0">
<channels default="ee">
<channel name="ee" stack="tcpping"/>
</channels>
<stacks>
<stack name="tcpping">
<transport type="TCP"
socket-binding="jgroups-tcp">
<property name="external_addr">
${jgroups.bind.address:127.0.0.1}
</property>
<property name="bind_addr">
${jgroups.bind_addr:SITE_LOCAL}
</property>
</transport>
<jdbc-protocol type="JDBC_PING"
data-source="KeycloakDS">
<property name="initialize_sql">
CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr varchar(200)
NOT NULL,bind_addr varchar(200) NOT NULL,created timestamp NOT NULL,cluster_name
varchar(200) NOT NULL,ping_data BYTEA,constraint PK_JGROUPSPING PRIMARY KEY (own_addr,
cluster_name))
</property>
<property name="insert_single_sql">
INSERT INTO JGROUPSPING (own_addr, bind_addr, created,
cluster_name, ping_data) values (?,'${jgroups.bind.address:127.0.0.1}',NOW(), ?,
?)
</property>
<property name="delete_single_sql">
DELETE FROM JGROUPSPING WHERE own_addr=? AND cluster_name=?
</property>
<property name="select_all_pingdata_sql">
SELECT ping_data FROM JGROUPSPING WHERE cluster_name=?;
</property>
</jdbc-protocol>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd">
<property name="external_addr">
${jgroups.bind.address:127.0.0.1}
</property>
</protocol>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
I do it in my own docker image where I change the configuration with jboss-cli (as in the
officilal) with this file :
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:remove
/subsystem=infinispan/cache-container=keycloak/replicated-cache=sessions:add()
/subsystem=infinispan/cache-container=keycloak/replicated-cache=sessions:write-attribute(name="mode",value="SYNC")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:remove
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:add(mode="SYNC",owners="2")
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:add(mode="SYNC",owners="2")
/subsystem=jgroups/stack=tcpping:add()
/subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp)
/subsystem=jgroups/stack=tcpping/transport=TCP/property=external_addr:add(value=${jgroups.bind.address:127.0.0.1})
/subsystem=jgroups/stack=tcpping/transport=TCP/property=bind_addr:add(value=${jgroups.bind_addr:SITE_LOCAL})
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING:add(data-source="KeycloakDS",
properties=[initialize_sql="CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr
varchar(200) NOT NULL,bind_addr varchar(200) NOT NULL,created timestamp NOT
NULL,cluster_name varchar(200) NOT NULL,ping_data BYTEA,constraint PK_JGROUPSPING PRIMARY
KEY (own_addr, cluster_name))",insert_single_sql="INSERT INTO JGROUPSPING
(own_addr, bind_addr, created, cluster_name, ping_data) values
(?,'${jgroups.bind.address:127.0.0.1}',NOW(), ?,
?)",delete_single_sql="DELETE FROM JGROUPSPING WHERE own_addr=? AND
cluster_name=?",select_all_pingdata_sql="SELECT ping_data FROM JGROUPSPING WHERE
cluster_name=?;"])
/subsystem=jgroups/stack=tcpping/protocol=MERGE3:add()
/subsystem=jgroups/stack=tcpping:add-protocol(type="FD_SOCK",socket-binding="jgroups-tcp-fd")
/subsystem=jgroups/stack=tcpping/protocol=FD_SOCK/property=external_addr:add(value=${jgroups.bind.address:127.0.0.1})
/subsystem=jgroups/stack=tcpping/protocol=FD:add()
/subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add()
/subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add()
/subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add()
/subsystem=jgroups/stack=tcpping/protocol=MFC:add()
/subsystem=jgroups/stack=tcpping/protocol=FRAG2:add()
/subsystem=jgroups/channel=ee:remove
/subsystem=jgroups/channel=ee:add(stack=tcpping)
/subsystem=jgroups:write-attribute(name=default-channel, value=ee)
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp:write-attribute(name="interface",value="private")
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:add()
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:write-attribute(name="interface",value="private")
/socket-binding-group=standard-sockets/socket-binding=jgroups-tcp-fd:write-attribute(name="port",value="57600")
/subsystem=jgroups/stack=tcp:remove
/subsystem=jgroups/stack=udp:remove
I am not sure all is good in this but it works (in my environment :) ).
(the difficulties I had was that if the cli file is like :
...
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING:add(data-source="KeycloakDS")
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING/property=datasource_jndi_name:add(value=java:jboss/datasources/KeycloakDS)
/subsystem=jgroups/stack=tcpping/protocol=JDBC_PING/property=otherproperty:add(value=other_value)
...
the configuration in xml is :
<protocol type="org.apache.jgroups.JDBC_PING" >
Which doesn't work (don't know why). There is not a lot of documentation on this,
so I'm listening to all suggestions.
Cheers,
Cédric Couralet
2058
days inactive
2059
days old
8 comments
5 participants
participants (5)
-
cedric＠couralet.eu -
Schuster Sebastian (INST-CSS/BSV-OS) -
Sebastian Laskawiec -
Stian Thorgersen -
Thomas Darimont