[JBoss JIRA] (WFLY-12224) CLI output is doubled after embed-server reload
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFLY-12224?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFLY-12224:
---------------------------------------------
It occurs even calling :reload operation.
The duplicated output comes from logging. [~jamezp], I solated the commit that introduced this:
https://github.com/wildfly/wildfly-core/commit/766c3991e2b11eedda4be83040...
> CLI output is doubled after embed-server reload
> -----------------------------------------------
>
> Key: WFLY-12224
> URL: https://issues.jboss.org/browse/WFLY-12224
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Logging
> Affects Versions: 18.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Jean Francois Denise
> Priority: Major
>
> CLI output is doubled after embed-server reload:
> {noformat}
> [okotek@localhost wildfly-18.0.0.Beta1-SNAPSHOT]$ ./bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] :whoami
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> [standalone@embedded /] reload
> [standalone@embedded /] :whoami
> 12:34:27,735 INFO [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4541) /subsystem=discovery/static-provider=foo:write-attribute operation fails with StackOverflowError
by Radoslav Husar (Jira)
Radoslav Husar created WFCORE-4541:
--------------------------------------
Summary: /subsystem=discovery/static-provider=foo:write-attribute operation fails with StackOverflowError
Key: WFCORE-4541
URL: https://issues.jboss.org/browse/WFCORE-4541
Project: WildFly Core
Issue Type: Bug
Components: Discovery
Reporter: Radoslav Husar
Assignee: Jeff Mesnil
{code}
[standalone@embedded /] /subsystem=discovery/static-provider=foo:write-attribute(name=services,value=[{uri=a:b:c}]
15:50:11,877 ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-2) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
("subsystem" => "discovery"),
("static-provider" => "foo")
]): java.lang.StackOverflowError
at java.util.Collections$UnmodifiableCollection$1.<init>(Collections.java:1039)
at java.util.Collections$UnmodifiableCollection.iterator(Collections.java:1038)
at org.jboss.as.controller.operations.validation.ModelTypeValidator.validateParameter(ModelTypeValidator.java:157)
at org.jboss.as.controller.operations.validation.StringLengthValidator.validateParameter(StringLengthValidator.java:86)
at org.jboss.as.controller.operations.validation.NillableOrExpressionParameterValidator.validateParameter(NillableOrExpressionParameterValidator.java:78)
at org.jboss.as.controller.AttributeDefinition.validateOperation(AttributeDefinition.java:1228)
at org.jboss.as.controller.AttributeDefinition.validateOperation(AttributeDefinition.java:491)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:70)
at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
...
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.StackOverflowError",
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4541) /subsystem=discovery/static-provider=foo:write-attribute operation fails with StackOverflowError
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFCORE-4541?page=com.atlassian.jira.plugi... ]
Paul Ferraro reassigned WFCORE-4541:
------------------------------------
Assignee: Paul Ferraro (was: Jeff Mesnil)
> /subsystem=discovery/static-provider=foo:write-attribute operation fails with StackOverflowError
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4541
> URL: https://issues.jboss.org/browse/WFCORE-4541
> Project: WildFly Core
> Issue Type: Bug
> Components: Discovery
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Major
>
> {code}
> [standalone@embedded /] /subsystem=discovery/static-provider=foo:write-attribute(name=services,value=[{uri=a:b:c}]
> 15:50:11,877 ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-2) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "discovery"),
> ("static-provider" => "foo")
> ]): java.lang.StackOverflowError
> at java.util.Collections$UnmodifiableCollection$1.<init>(Collections.java:1039)
> at java.util.Collections$UnmodifiableCollection.iterator(Collections.java:1038)
> at org.jboss.as.controller.operations.validation.ModelTypeValidator.validateParameter(ModelTypeValidator.java:157)
> at org.jboss.as.controller.operations.validation.StringLengthValidator.validateParameter(StringLengthValidator.java:86)
> at org.jboss.as.controller.operations.validation.NillableOrExpressionParameterValidator.validateParameter(NillableOrExpressionParameterValidator.java:78)
> at org.jboss.as.controller.AttributeDefinition.validateOperation(AttributeDefinition.java:1228)
> at org.jboss.as.controller.AttributeDefinition.validateOperation(AttributeDefinition.java:491)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:70)
> at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
> at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
> ...
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
> at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
> at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
> at org.wildfly.extension.discovery.StaticProviderAddHandler.modifyRegistrationModel(StaticProviderAddHandler.java:70)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.StackOverflowError",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12188) Option READ_TIMEOUT is ignored
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ]
Flavia Rainone updated WFLY-12188:
----------------------------------
Component/s: Remoting
> Option READ_TIMEOUT is ignored
> ------------------------------
>
> Key: WFLY-12188
> URL: https://issues.jboss.org/browse/WFLY-12188
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 17.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Flavia Rainone
> Priority: Blocker
>
> What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
> {code}
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
> <!-- server-side configuration -->
> <properties>
> <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
> <property name="KEEP_ALIVE" value="true"/>
> <property name="READ_TIMEOUT" value="10000"/>
> <property name="WRITE_TIMEOUT" value="10000"/>
> </properties>
> </http-connector>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12188) Option READ_TIMEOUT is ignored
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ]
Flavia Rainone updated WFLY-12188:
----------------------------------
Description:
What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
{code}
<remote connector-ref="http-remoting-connector" thread-pool-name="default">
<channel-creation-options>
<option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
<option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
</channel-creation-options>
</remote>
{code}
{code}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<endpoint/>
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<!-- server-side configuration -->
<properties>
<property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
<property name="KEEP_ALIVE" value="true"/>
<property name="READ_TIMEOUT" value="10000"/>
<property name="WRITE_TIMEOUT" value="10000"/>
</properties>
</http-connector>
{code}
None of those options work.
was:
What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
{code}
<remote connector-ref="http-remoting-connector" thread-pool-name="default">
<channel-creation-options>
<option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
<option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
</channel-creation-options>
</remote>
{code}
{code}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<endpoint/>
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<!-- server-side configuration -->
<properties>
<property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
<property name="KEEP_ALIVE" value="true"/>
<property name="READ_TIMEOUT" value="10000"/>
<property name="WRITE_TIMEOUT" value="10000"/>
</properties>
</http-connector>
{code}
> Option READ_TIMEOUT is ignored
> ------------------------------
>
> Key: WFLY-12188
> URL: https://issues.jboss.org/browse/WFLY-12188
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 17.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Flavia Rainone
> Priority: Blocker
>
> What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
> {code}
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
> <!-- server-side configuration -->
> <properties>
> <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
> <property name="KEEP_ALIVE" value="true"/>
> <property name="READ_TIMEOUT" value="10000"/>
> <property name="WRITE_TIMEOUT" value="10000"/>
> </properties>
> </http-connector>
> {code}
> None of those options work.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12188) Option READ_TIMEOUT is ignored
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ]
Flavia Rainone updated WFLY-12188:
----------------------------------
Summary: Option READ_TIMEOUT is ignored (was: What's the difference of the READ_TIMEOUT in ejb3 subsystem vs. remoting subsystem)
> Option READ_TIMEOUT is ignored
> ------------------------------
>
> Key: WFLY-12188
> URL: https://issues.jboss.org/browse/WFLY-12188
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Flavia Rainone
> Priority: Blocker
>
> What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
> {code}
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
> <!-- server-side configuration -->
> <properties>
> <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
> <property name="KEEP_ALIVE" value="true"/>
> <property name="READ_TIMEOUT" value="10000"/>
> <property name="WRITE_TIMEOUT" value="10000"/>
> </properties>
> </http-connector>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12188) What's the difference of the READ_TIMEOUT in ejb3 subsystem vs. remoting subsystem
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ]
Flavia Rainone updated WFLY-12188:
----------------------------------
Priority: Blocker (was: Major)
> What's the difference of the READ_TIMEOUT in ejb3 subsystem vs. remoting subsystem
> ----------------------------------------------------------------------------------
>
> Key: WFLY-12188
> URL: https://issues.jboss.org/browse/WFLY-12188
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Flavia Rainone
> Priority: Blocker
>
> What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
> {code}
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
> <!-- server-side configuration -->
> <properties>
> <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
> <property name="KEEP_ALIVE" value="true"/>
> <property name="READ_TIMEOUT" value="10000"/>
> <property name="WRITE_TIMEOUT" value="10000"/>
> </properties>
> </http-connector>
> {code}
--
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...]
* [eap-7.x-clustering-http-session-shutdown-scattered#10|https://eap-qe-jenk...]
The number of errors in the log files is *elevated*: about 1000-2000 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:
* [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...]
* [eap-7.x-clustering-http-session-shutdown-scattered#10|https://eap-qe-jenk...]
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...]
> * [eap-7.x-clustering-http-session-shutdown-scattered#10|https://eap-qe-jenk...]
> The number of errors in the log files is *elevated*: about 1000-2000 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
[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...]
* [eap-7.x-clustering-http-session-shutdown-scattered#10|https://eap-qe-jenk...]
The number of errors in the log files is elevated: about 1000-2000 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:
* [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...]
* [eap-7.x-clustering-http-session-shutdown-scattered#10|https://eap-qe-jenk...]
The number of errors in the log files is *elevated*: about 1000-2000 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...]
> * [eap-7.x-clustering-http-session-shutdown-scattered#10|https://eap-qe-jenk...]
> The number of errors in the log files is elevated: about 1000-2000 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