[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-2355:
------------------------------------
Would you prefer option 1 or option 2 from the description?
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip(). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2355:
--------------------------------
Yes, my fault: I was under the impression that
{noformat}
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
{noformat}
in the POM somehow forced javac to generate 8-compliant byte code...
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip(). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-2355:
-------------------------------
Description:
Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
{noformat}
WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
{noformat}
The problematic code seems to be here:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
N.B. There is a similar problem with uses of ByteBuffer.flip(). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
There are 2 ways to fix this:
1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
was:
Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
{noformat}
WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
{noformat}
The problematic code seems to be here:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
There are 2 ways to fix this:
1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip(). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-2355:
------------------------------------
Shouldn't the jars published in the maven repo be usable with JDK8 as advertised?
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-2355:
-------------------------------
Priority: Critical (was: Blocker)
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2355:
---------------------------
Fix Version/s: 4.1.2
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2355:
--------------------------------
Hi Paul
why is this a blocker? First, we're not using TCP_NIO2 by default and secondly, people can build their own JAR using JDK 8.
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12216) [GSS](7.2.z) Log WARN if application specifies @RunAsPrincipal and not @RunAs
by Teresa Miyar Gil (Jira)
[ https://issues.jboss.org/browse/WFLY-12216?page=com.atlassian.jira.plugin... ]
Teresa Miyar Gil moved JBEAP-17084 to WFLY-12216:
-------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12216 (was: JBEAP-17084)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Fix Version/s: (was: 7.2.4.GA)
> [GSS](7.2.z) Log WARN if application specifies @RunAsPrincipal and not @RunAs
> -----------------------------------------------------------------------------
>
> Key: WFLY-12216
> URL: https://issues.jboss.org/browse/WFLY-12216
> Project: WildFly
> Issue Type: Bug
> Reporter: Teresa Miyar Gil
> Assignee: Teresa Miyar Gil
> Priority: Major
>
> Log WARN if application specifies @RunAsPrincipal and not @RunAs
> As per: https://docs.jboss.org/author/display/WFLY10/EJB+3+Reference+Guide
> Specification of Run-as Principal using Metadata Annotations
> ...
> Using this annotation without specifying a run-as role is considered an error.
> For example:
> {code}
> @RunAs("admin")
> @RunAsPrincipal("MyBean")
> {code}
> If a user specifies @RunAsPrincipal and not @RunAs (or the xml equivalent), then the user shows up as anonymous, we should log a warning to let the application know that there is an issue so that they know it needs to be corrected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12216) Log WARN if application specifies @RunAsPrincipal and not @RunAs
by Teresa Miyar Gil (Jira)
[ https://issues.jboss.org/browse/WFLY-12216?page=com.atlassian.jira.plugin... ]
Teresa Miyar Gil updated WFLY-12216:
------------------------------------
Summary: Log WARN if application specifies @RunAsPrincipal and not @RunAs (was: [GSS](7.2.z) Log WARN if application specifies @RunAsPrincipal and not @RunAs)
> Log WARN if application specifies @RunAsPrincipal and not @RunAs
> ----------------------------------------------------------------
>
> Key: WFLY-12216
> URL: https://issues.jboss.org/browse/WFLY-12216
> Project: WildFly
> Issue Type: Bug
> Reporter: Teresa Miyar Gil
> Assignee: Teresa Miyar Gil
> Priority: Major
>
> Log WARN if application specifies @RunAsPrincipal and not @RunAs
> As per: https://docs.jboss.org/author/display/WFLY10/EJB+3+Reference+Guide
> Specification of Run-as Principal using Metadata Annotations
> ...
> Using this annotation without specifying a run-as role is considered an error.
> For example:
> {code}
> @RunAs("admin")
> @RunAsPrincipal("MyBean")
> {code}
> If a user specifies @RunAsPrincipal and not @RunAs (or the xml equivalent), then the user shows up as anonymous, we should log a warning to let the application know that there is an issue so that they know it needs to be corrected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12214) JGRP000029: failed sending message: java.net.ConnectException: Connection refused
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12214?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12214:
------------------------------------
Description:
The error is observed in fail-over clustering tests where fail-over is "shutdown" and the jgroups stack is TCP.
The error was not observed in:
* wildfly-17.0.0.Final.zip
* wildfly-16.0.0.Final.zip
Right after one node (wildfly1) is shut down and restarted and the next node (wildfly2) is shut down we see:
{noformat}
2019-06-20 10:55:07,021 INFO [org.infinispan.CLUSTER] (thread-84,ejb,wildfly1) ISPN000094: Received new cluster view for channel ejb: [wildfly3|6] (3) [wildfly3, wildfly4, wildfly1]
2019-06-20 10:55:07,022 INFO [org.infinispan.CLUSTER] (thread-84,ejb,wildfly1) ISPN100001: Node wildfly2 left the cluster
2019-06-20 10:55:07,109 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
2019-06-20 10:55:07,251 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
2019-06-20 10:55:07,342 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
2019-06-20 10:55:07,437 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
{noformat}
Complete logs:
* [eap-7.x-clustering-db-session-shutdown-repl-mssql-2016#2|https://eap-qe-j...]
* [eap-7.x-clustering-http-session-granular-dist-jvmkill-haproxy#4|https://e...]
The number of errors is about 1000 per node;
Overall fail-rate is still close to 0%.
was:
The error is observed in fail-over clustering tests where fail-over is "shutdown" and the jgroups stack is TCP.
The error was not observed in:
* wildfly-17.0.0.Final.zip
* wildfly-16.0.0.Final.zip
Right after one node (wildfly1) is shut down and restarted and the next node (wildfly2) is shut down we see:
{noformat}
2019-06-20 10:55:07,021 INFO [org.infinispan.CLUSTER] (thread-84,ejb,wildfly1) ISPN000094: Received new cluster view for channel ejb: [wildfly3|6] (3) [wildfly3, wildfly4, wildfly1]
2019-06-20 10:55:07,022 INFO [org.infinispan.CLUSTER] (thread-84,ejb,wildfly1) ISPN100001: Node wildfly2 left the cluster
2019-06-20 10:55:07,109 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
2019-06-20 10:55:07,251 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
2019-06-20 10:55:07,342 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
2019-06-20 10:55:07,437 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
{noformat}
Complete logs [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/vie...].
The number of errors is about 1000 per node;
Overall fail-rate is still close to 0%.
> JGRP000029: failed sending message: java.net.ConnectException: Connection refused
> ---------------------------------------------------------------------------------
>
> Key: WFLY-12214
> URL: https://issues.jboss.org/browse/WFLY-12214
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Major
>
> The error is observed in fail-over clustering tests where fail-over is "shutdown" and the jgroups stack is TCP.
> The error was not observed in:
> * wildfly-17.0.0.Final.zip
> * wildfly-16.0.0.Final.zip
> Right after one node (wildfly1) is shut down and restarted and the next node (wildfly2) is shut down we see:
> {noformat}
> 2019-06-20 10:55:07,021 INFO [org.infinispan.CLUSTER] (thread-84,ejb,wildfly1) ISPN000094: Received new cluster view for channel ejb: [wildfly3|6] (3) [wildfly3, wildfly4, wildfly1]
> 2019-06-20 10:55:07,022 INFO [org.infinispan.CLUSTER] (thread-84,ejb,wildfly1) ISPN100001: Node wildfly2 left the cluster
> 2019-06-20 10:55:07,109 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
> 2019-06-20 10:55:07,251 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
> 2019-06-20 10:55:07,342 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
> 2019-06-20 10:55:07,437 ERROR [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,wildfly1) JGRP000029: wildfly1: failed sending message to wildfly2 (133 bytes): java.net.ConnectException: Connection refused (Connection refused), headers: FORK: ejb:web, UNICAST3: DATA, seqno=44773, TP: [cluster=ejb]
> {noformat}
> Complete logs:
> * [eap-7.x-clustering-db-session-shutdown-repl-mssql-2016#2|https://eap-qe-j...]
> * [eap-7.x-clustering-http-session-granular-dist-jvmkill-haproxy#4|https://e...]
> The number of errors is about 1000 per node;
> Overall fail-rate is still close to 0%.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months