[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 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:
* [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 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
[JBoss JIRA] (WFCORE-3747) Enhance credential-store description related to location and type attributes
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3747?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3747:
------------------------------------------
The issue here is a little more complex than the description.
The type attribute does not actually default to JCEKS, it does genuinely default to undefined / null.
The problem is there is a second value 'keyStoreType which is used to specify the type of the key store used by the credential store which is independent of the actual key store implementation, this value can be set within the implementation-properties. Any value set in the implementation-properties takes precedence.
If the type attribute is not defined or the type attribute is set to KeyStoreCredentialStore then if (and only if) no keyStoreType is specified we assume the keyStoreType should be JCEKS.
_Note: We never set the type value to JCEKS, that realms set to null._
Now in relation to the location attribute that actually checks if the 'keyStoreType' as been set to one of JKS, JCEKS, and PKCS12 after the evaluation described above. This means it would not be a simple update to the description above.
I think I need to double check some configuration options to verify a null type really does make sense.
Other than that I think this is a sign this is a complex resource with some in-depth validation requirements which make automatic validation difficult (TBH any validation applied to a Map based configuration is always error prone). We may want to revisit the resource definition at some point as it is also not following the pattern we used for other resources in the subsystem.
As an example for other capabilities we provide in our subsystem we provide dedicated resources for each implementation, this means our configuration is very focused on the requirements of that implementation allowing us to both declare the validation and execute it. We then additionally add a resource for custom implementations with generic configuration that we do not validate. This may be what we need to do here - split the resource into two or more resources and deprecate this one.
On other resources where a capabilities results in exposing the same management operations on multiple resources we use a decorator pattern to add those additional methods, that same pattern would still be applicable to credential stores.
In the meantime I am documenting the credential store under WFLY-11101 as we have identified community documentation is missing. Unless we end up with some free time towards the end of WildFly 18 now is not the time to refactor this resource so instead we may need to rely on the documentation rather than the model description.
> Enhance credential-store description related to location and type attributes
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3747
> URL: https://issues.jboss.org/browse/WFCORE-3747
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The description for "location" and "type" for credential-store resource is displayed below.
> Following discussion of WFCORE-3458, the "location" attribute is required only when the "type" is file based, but the description doesn't says that, the description may be improved to reflect this behavior and list the possible file based types.
> When the user doesn't set the "type" attribute it defaults to "JCEKS", but there is no "default" value on resource description for "type" attribute.
> {code}
> "location" => {
> "type" => STRING,
> "description" => "File name of credential store storage.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "type" => {
> "type" => STRING,
> "description" => "The credential store type, e.g. KeyStoreCredentialStore.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {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 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:
* [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 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
[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 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:
* [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%.
> 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 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
[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 updated WFLY-12224:
----------------------------------------
Component/s: Logging
> 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-4540) Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4540?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-4540:
-------------------------------------
Fix Version/s: 10.0.0.Beta1
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4540
> URL: https://issues.jboss.org/browse/WFCORE-4540
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
> This CLI commands
> {code}
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
> {code}
> end with success result.
> {code}
> {
> "outcome" => "success",
> "result" => undefined
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4540) Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4540?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-4540:
----------------------------------------
Assignee: Darran Lofthouse
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4540
> URL: https://issues.jboss.org/browse/WFCORE-4540
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
> This CLI commands
> {code}
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
> {code}
> end with success result.
> {code}
> {
> "outcome" => "success",
> "result" => undefined
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4540) Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4540?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved ELY-651 to WFCORE-4540:
----------------------------------------------
Project: WildFly Core (was: WildFly Elytron)
Key: WFCORE-4540 (was: ELY-651)
Component/s: Security
(was: Credential Store)
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4540
> URL: https://issues.jboss.org/browse/WFCORE-4540
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
> This CLI commands
> {code}
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
> {code}
> end with success result.
> {code}
> {
> "outcome" => "success",
> "result" => undefined
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4205) DMN: UI enhancements for Data Type editor
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4205?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-4205:
--------------------------------------
Story Points: 8 (was: 13)
> DMN: UI enhancements for Data Type editor
> -----------------------------------------
>
> Key: DROOLS-4205
> URL: https://issues.jboss.org/browse/DROOLS-4205
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> *User Story*
> As a practitioner I want to be able to:
> * select an existing data type
> * create a simple or structured data type
> * create a “compound” (or complex) data type, easily.
> *
expand/collapse views of compound data types, so that I can___
> *
navigate between levels in a compound data type, so that I can___
> * edit an existing data type
> * remove an existing data type
>
…so that I can use the data type when creating a decision related asset.
> Requested UI enhancements, based on feedback from 7.4 implementation (keyboard shortcuts are covered in a separate Epic)
> * NESTING ISSUES ARE HIGH PRIORITY
> - Fix Dropdown menu labeling (Structure)
> - Weird tooltip on Structured row.
> - It wasn’t clear wasn’t what was nested, and looking for drag-n-drop to nest and reorder.
> - Finding “Structure” in the dropdown - was separate, blue and at the bottom. Terminology.
> - Nested data types, - all 3 used the field already open, but confusion about adding additional rows. Kebab didn’t work so well. Terminology for kebab menu.
> - Due to the icon at the top level and no icons at the second level, the indenting of second level items is not very clear for users. Make sure the nesting is very clear at a glance.
> - Better way to add a new field that is always visible to the user and clear to use without having to go into a kabob menu
> RELATED SAVE INTERACTIONS (Save, Delete, Remove)
> - Inline editing of the content in the rows would make the experience nicer than having a whole row edit model
> - - It's not obvious that you have to select the "check mark" to commit the change.
> - After adding a new data type field, undo becomes available but instead of removing the field, it resets the field name and type to the defaults. Redo then becomes available but doesn't appear to do anything when clicked.
> OTHER:
> - “Constraint” link was confusing, but location was good.
> - In the dialog, “Add” wasn’t found too well. (Bug adding a null constraint.)
> - Questions around Save - should it not require Save at the row level.
> - It feels unnatural to have to click the "Constraints" to open the Constraints modal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-3784) Increase the advanced user productivity when he creates a new Data Type
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3784?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3784:
--------------------------------------
Parent: DROOLS-4205
Issue Type: Sub-task (was: Story)
> Increase the advanced user productivity when he creates a new Data Type
> -----------------------------------------------------------------------
>
> Key: DROOLS-3784
> URL: https://issues.jboss.org/browse/DROOLS-3784
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Donato Marrazzo
> Assignee: Elizabeth Clayton
> Priority: Minor
> Labels: Field, UX, UXTeam, drools-tools
> Attachments: DT_List1.png, DT_List1b.png, Screenshot from 2019-03-25 15-27-51.png, constraints.png, nested.png, type-selector.png
>
>
> The Data Type editor could be improved in terms of productivity and usability.
> Ideally, the user should be able to create a complex type minimizing the mouse usage.
> 1) Saving the node is an overhead for basic data type (e.g. age: number)
> 2) Some actions in the kebab menu should be more visible and available even before saving the type (as standalone icon / buttons). Especially, insert nested, delete.
> 3) Select type in the selector by typing the name of the type (see screenshot): it already works but it consider just the first letter typed. Since, by convention, all custom types starts with `t` letter, it would be better consider at least 2 letters.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months