[JBoss JIRA] (JGRP-2301) UFC: add back to configs even if TCP is transport
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2301?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2301.
----------------------------
Resolution: Done
> UFC: add back to configs even if TCP is transport
> -------------------------------------------------
>
> Key: JGRP-2301
> URL: https://issues.jboss.org/browse/JGRP-2301
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.16
>
>
> Currently, none of the TCP-based stacks have UFC in them. This is bad, as async messages can overwhelm the receiver. Point in case is cross-site replication: the bridge using TCP replicates updates to the other site masters quickly, but the updates are only passed to the thread pool for processing, exhausting memory over time.
> Although TCP does perform flow control, the application code at the receiver may delay delivery and thus the sender would block if UFC was present.
> However, the absence of UFC leads to thread pool (and queue) overflow at the receiver(s) if messages are constantly sent at a rate greater that when the receiver(s) can process.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3258) [DMN Designer] Import external DMN file
by Guilherme Carreiro (Jira)
Guilherme Carreiro created DROOLS-3258:
------------------------------------------
Summary: [DMN Designer] Import external DMN file
Key: DROOLS-3258
URL: https://issues.jboss.org/browse/DROOLS-3258
Project: Drools
Issue Type: Epic
Components: DMN Editor
Reporter: Guilherme Carreiro
Assignee: Guilherme Carreiro
This is a R&D task.
Check DMN spec, the current code, break the initial tasks and update this description for the import feature.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (JGRP-2301) UFC: add back to configs even if TCP is transport
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2301?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2301:
--------------------------------
This was observed in an actual customer case where cross-site replication done *asynchronously* led to OOMEs on the receivers.
> UFC: add back to configs even if TCP is transport
> -------------------------------------------------
>
> Key: JGRP-2301
> URL: https://issues.jboss.org/browse/JGRP-2301
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.16
>
>
> Currently, none of the TCP-based stacks have UFC in them. This is bad, as async messages can overwhelm the receiver. Point in case is cross-site replication: the bridge using TCP replicates updates to the other site masters quickly, but the updates are only passed to the thread pool for processing, exhausting memory over time.
> Although TCP does perform flow control, the application code at the receiver may delay delivery and thus the sender would block if UFC was present.
> However, the absence of UFC leads to thread pool (and queue) overflow at the receiver(s) if messages are constantly sent at a rate greater that when the receiver(s) can process.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (JGRP-2301) UFC: add back to configs even if TCP is transport
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2301?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2301:
---------------------------
Description:
Currently, none of the TCP-based stacks have UFC in them. This is bad, as async messages can overwhelm the receiver. Point in case is cross-site replication: the bridge using TCP replicates updates to the other site masters quickly, but the updates are only passed to the thread pool for processing, exhausting memory over time.
Although TCP does perform flow control, the application code at the receiver may delay delivery and thus the sender would block if UFC was present.
However, the absence of UFC leads to thread pool (and queue) overflow at the receiver(s) if messages are constantly sent at a rate greater that when the receiver(s) can process.
was:Currently, none of the TCP-based stacks have UFC in them. This is bad, as async messages can overwhelm the receiver. Point in case is cross-site replication: the bridge using TCP replicates updates to the other site masters quickly, but the updates are only passed to the thread pool for processing, exhausting memory over time.
> UFC: add back to configs even if TCP is transport
> -------------------------------------------------
>
> Key: JGRP-2301
> URL: https://issues.jboss.org/browse/JGRP-2301
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.16
>
>
> Currently, none of the TCP-based stacks have UFC in them. This is bad, as async messages can overwhelm the receiver. Point in case is cross-site replication: the bridge using TCP replicates updates to the other site masters quickly, but the updates are only passed to the thread pool for processing, exhausting memory over time.
> Although TCP does perform flow control, the application code at the receiver may delay delivery and thus the sender would block if UFC was present.
> However, the absence of UFC leads to thread pool (and queue) overflow at the receiver(s) if messages are constantly sent at a rate greater that when the receiver(s) can process.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (JGRP-2300) DNS_PING in AWS ECS cannot cluster with dynamic port mappings
by Sebastian Łaskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2300?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2300:
-------------------------------------------
Unfortunately no, I'm currently busy with other priority tasks.
[~ethompson] Perhaps you'd be interested in donating us a patch for this?
> DNS_PING in AWS ECS cannot cluster with dynamic port mappings
> -------------------------------------------------------------
>
> Key: JGRP-2300
> URL: https://issues.jboss.org/browse/JGRP-2300
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.16
> Environment: AWS ECS Cluster with DNS based service discovery using jboss/keycloak:latest containers
> Reporter: Eric Thompson
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 4.0.16
>
>
> When running an ECS cluster with jboss/keycloak:latest containers dynamic port mapping of all ports is required to allow more than one container to run per EC2 instance. Using SRV based service discovery records will allow each node to find the rest of the nodes, but when a discovery request is sent the receiving node sees the sender as IP:7600 instead of the dynamic port. It then sees this as a "new" node and tries to send discovery requests to it. And somehow it is also getting node IDs and trying to send requests to those!
> See the following log, there are only 4 actual nodes and the each have a different 5 digit port number:
> {code}
> ### Service discovery with dynamic port mapping
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:32949, 10.42.3.56:32951, 10.42.3.44:32954, c5b479b7b6d5, 10.42.3.44:32952, 10.42.3.56:7600, 17081c624290, 63976b7fae70, 557cbd7891a2]
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:7600
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32949
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32951
> 2018-10-10 20:17:44,180 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32954
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to c5b479b7b6d5
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32952
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 17081c624290
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-238,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 63976b7fae70
> 2018-10-10 20:17:44,183 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 557cbd7891a2
> 2018-10-10 20:17:44,187 WARN [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,17081c624290) JGRP000032: 17081c624290: no physical address for c5b479b7b6d5, dropping message
> {code}
> This code seems to be part of the problem in this case: https://github.com/belaban/JGroups/blob/87d15ec848aa3d482ae792ef152f7e36e...
> See that code uses the incoming address and adds it to the discocvered_hosts, but those addresses are ALWAYS inaccurate in this case.
> Because this is what the recipient of the service discovery request sees (ie: all the ports are the default 7600):
> {code}
> 2018-10-10 20:35:15,229 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,231 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,232 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,233 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,234 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,236 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,239 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,240 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,242 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,243 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,246 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,249 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,252 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,255 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,256 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> {code}
> In this state the cluster never seems to work properly and the Keycloak interface breaks in many frustrating ways.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3030) [DMN Designer] Expand / Collapse all
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3030?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3030:
---------------------------------------
Sprint: (was: 2018 Week 45-47)
> [DMN Designer] Expand / Collapse all
> ------------------------------------
>
> Key: DROOLS-3030
> URL: https://issues.jboss.org/browse/DROOLS-3030
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: UX, drools-tools
>
> User should have possibility to easily expand / collapse all data types in the *manage custom data type* dialog.
> h2. Manual acceptance test
> - Expand
> -- All collapsed initially
> -- Something collapsed initially, something expanded already
> -- All expanded already
> - Collapse
> -- All expanded initially
> -- Something expanded initially, something collapsed already
> -- All collapsed already
> - No error warning in browser console log
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3235) [DMN Designer] Runtime issues [7.3.x]
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3235?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3235:
-----------------------------------
Epic Name: [DMN Designer] Runtime issues [7.2.0.Final] (was: [DMN Designer] Runtime issues [7.3.x])
> [DMN Designer] Runtime issues [7.3.x]
> -------------------------------------
>
> Key: DROOLS-3235
> URL: https://issues.jboss.org/browse/DROOLS-3235
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> An umbrella for the issues we're encountering with _using_ DMN models authored with _our_ editor. A lot of issues are being reported as comments on PRs or as separate JIRA. In reality, in preparation for our MVP we need to be confident all such issues are captured, fixed and re-tested.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3235) [DMN Designer] Runtime issues [7.2.0.Final]
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3235?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3235:
-----------------------------------
Summary: [DMN Designer] Runtime issues [7.2.0.Final] (was: [DMN Designer] Runtime issues [7.3.x])
> [DMN Designer] Runtime issues [7.2.0.Final]
> -------------------------------------------
>
> Key: DROOLS-3235
> URL: https://issues.jboss.org/browse/DROOLS-3235
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> An umbrella for the issues we're encountering with _using_ DMN models authored with _our_ editor. A lot of issues are being reported as comments on PRs or as separate JIRA. In reality, in preparation for our MVP we need to be confident all such issues are captured, fixed and re-tested.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (JGRP-2300) DNS_PING in AWS ECS cannot cluster with dynamic port mappings
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2300?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2300:
--------------------------------
Any updates on this? I'm working on releasing 4.0.16...
> DNS_PING in AWS ECS cannot cluster with dynamic port mappings
> -------------------------------------------------------------
>
> Key: JGRP-2300
> URL: https://issues.jboss.org/browse/JGRP-2300
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.16
> Environment: AWS ECS Cluster with DNS based service discovery using jboss/keycloak:latest containers
> Reporter: Eric Thompson
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 4.0.16
>
>
> When running an ECS cluster with jboss/keycloak:latest containers dynamic port mapping of all ports is required to allow more than one container to run per EC2 instance. Using SRV based service discovery records will allow each node to find the rest of the nodes, but when a discovery request is sent the receiving node sees the sender as IP:7600 instead of the dynamic port. It then sees this as a "new" node and tries to send discovery requests to it. And somehow it is also getting node IDs and trying to send requests to those!
> See the following log, there are only 4 actual nodes and the each have a different 5 digit port number:
> {code}
> ### Service discovery with dynamic port mapping
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:32949, 10.42.3.56:32951, 10.42.3.44:32954, c5b479b7b6d5, 10.42.3.44:32952, 10.42.3.56:7600, 17081c624290, 63976b7fae70, 557cbd7891a2]
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:7600
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32949
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32951
> 2018-10-10 20:17:44,180 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32954
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to c5b479b7b6d5
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32952
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 17081c624290
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-238,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 63976b7fae70
> 2018-10-10 20:17:44,183 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 557cbd7891a2
> 2018-10-10 20:17:44,187 WARN [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,17081c624290) JGRP000032: 17081c624290: no physical address for c5b479b7b6d5, dropping message
> {code}
> This code seems to be part of the problem in this case: https://github.com/belaban/JGroups/blob/87d15ec848aa3d482ae792ef152f7e36e...
> See that code uses the incoming address and adds it to the discocvered_hosts, but those addresses are ALWAYS inaccurate in this case.
> Because this is what the recipient of the service discovery request sees (ie: all the ports are the default 7600):
> {code}
> 2018-10-10 20:35:15,229 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,231 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,232 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,233 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,234 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,236 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,239 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,240 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,242 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,243 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,246 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,249 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,252 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,255 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,256 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> {code}
> In this state the cluster never seems to work properly and the Keycloak interface breaks in many frustrating ways.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months