[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
* Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Capturing and resending of messages by R: YES (will get dropped by either {{NAKACK2}} or {{UNICAST3}})
* Capturing and resending of messages as _new messages_ by R: YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios to test (ENCRYPTTest)
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> h4. Properties
> * Rogue non-member R
> * Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
> * Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
> * Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
> * Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Capturing and resending of messages by R: YES (will get dropped by either {{NAKACK2}} or {{UNICAST3}})
* Capturing and resending of messages as _new messages_ by R: YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Capturing and resending of messages by R: YES (will get dropped by either {{NAKACK2}} or {{UNICAST3}})
* Capturing and resending of messages as _new messages_ by R: YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: NO, as {{ENCRYPT}} will drop them
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios to test (ENCRYPTTest)
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> h4. Properties
> * Rogue non-member R
> * Capturing and resending of messages by R: YES (will get dropped by either {{NAKACK2}} or {{UNICAST3}})
> * Capturing and resending of messages as _new messages_ by R: YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
> * Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
> * Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-1069) UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple
by Anantjot Anand (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1069?page=com.atlassian.jira.plugi... ]
Anantjot Anand updated DROOLS-1069:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1069
> URL: https://issues.jboss.org/browse/DROOLS-1069
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Anantjot Anand
> Assignee: Mark Proctor
>
> BaseLeftTuple class is inherited by EvalNodeLeftTuple, FromNodeLeftTuple, JoinNodeLeftTuple, LeftTupleImpl, NotNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple, RuleTerminalNodeLeftTuple classes.
> FromNodeLeftTuple, JoinNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple and RuleTerminalNodeLeftTuple doesn’t implement its overridden methods.
> at org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
> at org.drools.core.phreak.PhreakExistsNode.doLeftDeletes(PhreakExistsNode.java:425)
> at org.drools.core.phreak.PhreakExistsNode.doNode(PhreakExistsNode.java:53)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:560)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at com.wellsfargo.ARGenT.Execution.RuleBase.processDataWithRules(RuleBase.java:1618)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-1069) UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple
by Anantjot Anand (JIRA)
Anantjot Anand created DROOLS-1069:
--------------------------------------
Summary: UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple
Key: DROOLS-1069
URL: https://issues.jboss.org/browse/DROOLS-1069
Project: Drools
Issue Type: Feature Request
Affects Versions: 6.3.0.Final
Reporter: Anantjot Anand
Assignee: Mark Proctor
BaseLeftTuple class is inherited by EvalNodeLeftTuple, FromNodeLeftTuple, JoinNodeLeftTuple, LeftTupleImpl, NotNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple, RuleTerminalNodeLeftTuple classes.
FromNodeLeftTuple, JoinNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple and RuleTerminalNodeLeftTuple doesn’t implement its overridden methods.
at org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
at org.drools.core.phreak.PhreakExistsNode.doLeftDeletes(PhreakExistsNode.java:425)
at org.drools.core.phreak.PhreakExistsNode.doNode(PhreakExistsNode.java:53)
at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:560)
at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
at com.wellsfargo.ARGenT.Execution.RuleBase.processDataWithRules(RuleBase.java:1618)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Capturing and resending of messages by R: YES (will get dropped by either {{NAKACK2}} or {{UNICAST3}})
* Capturing and resending of messages as _new messages_ by R: YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: NO, as {{ENCRYPT}} will drop them
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios to test (ENCRYPTTest)
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> h4. Properties
> * Rogue non-member R
> * Capturing and resending of messages by R: YES (will get dropped by either {{NAKACK2}} or {{UNICAST3}})
> * Capturing and resending of messages as _new messages_ by R: YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
> * Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
> * Cluster members receiving messages from R: NO, as {{ENCRYPT}} will drop them
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test (ENCRYPTTest)
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios to test (ENCRYPTTest)
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFCORE-1409) Java 8 Functions for runtime attributes.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1409?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1409:
-------------------------------------
Fix Version/s: (was: 3.0.0.Alpha1)
> Java 8 Functions for runtime attributes.
> ----------------------------------------
>
> Key: WFCORE-1409
> URL: https://issues.jboss.org/browse/WFCORE-1409
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
>
> With Java 8 functions it should be possible to simplify how the values for runtime attributes are returned where resources register a single service.
> i.e. It should be possible to define a function that given the return type of the service returns another value based on the service returned value which is the value for the runtime attribute.
> As resources can also be closely related to the service based on capabilities this should be easier to resolve than it has been previously.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-6282) exceptions in 2-clusters EJB invocation graceful shutdown tests
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6282?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-6282:
----------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> exceptions in 2-clusters EJB invocation graceful shutdown tests
> ---------------------------------------------------------------
>
> Key: WFLY-6282
> URL: https://issues.jboss.org/browse/WFLY-6282
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Richard Achmatowicz
> Priority: Critical
>
> I have tests that start 2 clusters and a standalone EJB client and do remote EJB invocations like this: standalone EJB client -> cluster 1 (forwarder) -> cluster 2 (target) -> back to cluster 1 -> back to standalone client.
> During a graceful shutdown variant of such tests, I've seen two unexpected exceptions.
> ----
> This one happens during the time the graceful shutdown is initiated. I remember that transactions don't yet support graceful shutdown, so maybe that's the cause? There's an {{IOException: Channel ... of Remoting connection ... to localhost/127.0.0.1:8280 has been closed}} down there, so maybe my guess about graceful shutdown is wrong?
> {code}
> javax.ejb.EJBException: javax.transaction.HeuristicMixedException
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:138)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:119)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy26.test(Unknown Source)
> at org.jboss.qa.eap.clustering.[redacted].tools.ClientThread.doCall(ClientThread.java:75)
> at org.jboss.qa.eap.clustering.[redacted].tools.ClientThread.run(ClientThread.java:56)
> Caused by: javax.transaction.HeuristicMixedException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1208)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Suppressed: javax.transaction.xa.XAException
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.sendCommit(RemotingConnectionEJBReceiver.java:513)
> at org.jboss.ejb.client.EJBClientManagedTransactionContext$ResourceImpl.commit(EJBClientManagedTransactionContext.java:239)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:704)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2366)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1495)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> ... 48 more
> Caused by: java.io.IOException: Channel Channel ID da0eb13a (outbound) of Remoting connection 5caac271 to localhost/127.0.0.1:8280 has been closed
> at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:123)
> at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:115)
> at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:514)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:419)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:290)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeReadsAndWrites(RemoteConnectionChannel.java:274)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:534)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:372)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:437)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.receiveCloseRequest(RemoteConnectionHandler.java:217)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:111)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)
> {code}
> ----
> This one happens when all nodes are running. It also happens in a scenario where failure isn't graceful shutdown but JVM process kill, so maybe it isn't really related to graceful shutdown.
> {code}
> javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy26.test(Unknown Source)
> at org.jboss.qa.eap.clustering.[redacted].tools.ClientThread.doCall(ClientThread.java:75)
> at org.jboss.qa.eap.clustering.[redacted].tools.ClientThread.run(ClientThread.java:56)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:203)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:258)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:278)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy63.test(Unknown Source)
> at org.jboss.qa.eap.clustering.[redacted].ForwardingBeanImpl.test(ForwardingBeanImpl.java:30)
> at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Links to test code and Jenkins job are in a private comment below.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFCORE-1409) Java 8 Functions for runtime attributes.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1409:
----------------------------------------
Summary: Java 8 Functions for runtime attributes.
Key: WFCORE-1409
URL: https://issues.jboss.org/browse/WFCORE-1409
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha1
With Java 8 functions it should be possible to simplify how the values for runtime attributes are returned where resources register a single service.
i.e. It should be possible to define a function that given the return type of the service returns another value based on the service returned value which is the value for the runtime attribute.
As resources can also be closely related to the service based on capabilities this should be easier to resolve than it has been previously.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-6178) Clean shutdown of server with Artemis configured as backup logs warning
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6178?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reopened WFLY-6178:
-------------------------------
The previous PR was not fixing the issue, it generated a NPE if the activeMQActivationController was null and the service was shutting down
> Clean shutdown of server with Artemis configured as backup logs warning
> -----------------------------------------------------------------------
>
> Key: WFLY-6178
> URL: https://issues.jboss.org/browse/WFLY-6178
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> In one of our failover tests there is logged error to server.log during clean shutdown of EAP 7.0.0.ER5 with Artemis configured as backup. (see attach config) This error is not expected and should not appear.
> Error log:
> {code}
> 12:18:19,509 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=5d29fceb-cfd3-11e5-a0c8-11ddbbd9fb5b) AMQ224000: Failure in initialisation: java.lang.IllegalStateException: Container is down
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:716) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$3.activated(JMSService.java:154) [wildfly-messaging-activemq-7.0.0.ER5-redhat-1.jar:7.0.0.ER5-redhat-1]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivateCallbacks(ActiveMQServerImpl.java:1421) [artemis-server-1.1.0.redhat-7.jar:1.1.0.redhat-7]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1616) [artemis-server-1.1.0.redhat-7.jar:1.1.0.redhat-7]
> at org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:85) [artemis-server-1.1.0.redhat-7.jar:1.1.0.redhat-7]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0