[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-12317:
-------------------------------
Description:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (old and new node-identifier on both servers are same)
was:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (old and new node-identifiers on both servers are same)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Michael Musgrove
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move object store directory to the server2
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 7/23/19 10:03 AM:
----------------------------------------------------------------------
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a SLSB deployed on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established and used to reset the strong and weak affinity defined in the EJBInvocationHandler. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node, and which is largely determined by the type of bean the proxy represents and where the last invocation successfully executed.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() in the ObjectResolver for the Marshaller are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above. The purpose of this affinity adjustment (IIUC) is to be able to define all proxies created on the server as having Affinity.LOCAL and then use the marshaling trick to adjust the affinities correctly, depending on which client they are passed to.
It's important to keep these two aspects separated, as things can otherwise get very confusing.
was (Author: rachmato):
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a SLSB deployed on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established and used to reset the strong and weak affinity defined in the EJBInvocationHandler. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node, and which is largely determined by the type of bean the proxy represents and where the last invocation successfully executed.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() in the ObjectResolver for the Marshaller are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above.
It's important to keep these two aspects separated, as things can otherwise get very confusing.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip, test-debug-log.txt
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 7/23/19 10:00 AM:
----------------------------------------------------------------------
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a SLSB deployed on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established and used to reset the strong and weak affinity defined in the EJBInvocationHandler. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node, and which is largely determined by the type of bean the proxy represents and where the last invocation successfully executed.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() in the ObjectResolver for the Marshaller are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above.
It's important to keep these two aspects separated, as things can otherwise get very confusing.
was (Author: rachmato):
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node, and which is largely determined by the type of bean the proxy represents and where the last invocation successfully executed.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() in the ObjectResolver for the Marshaller are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above.
It's important to keep these two aspects separated, as things can otherwise get very confusing.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip, test-debug-log.txt
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 7/23/19 9:59 AM:
---------------------------------------------------------------------
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node, and which is largely determined by the type of bean the proxy represents and where the last invocation successfully executed.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() in the ObjectResolver for the Marshaller are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above.
It's important to keep these two aspects separated, as things can otherwise get very confusing.
was (Author: rachmato):
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above.
It's important to keep these two aspects separated.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip, test-debug-log.txt
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-12317:
-------------------------------
Steps to Reproduce:
git clone git@gitlab.mw.lab.eng.bos.redhat.com:jbossqe-eap/tests-transactions.git
get wildfly dist
mvn clean verify -Djboss.dist=__PATH_TO_DIST__ -Dtest=TxDifferentNodeCrashRecoveryTestCase#prepareHalt -DfailIfNoTests=false -Djbossts.noJTS -Dts.jbossts1.node.identifier=vkcd -Dts.jbossts2.node.identifier=FdOu -Dts.jbossts3.node.identifier=GocW
was:
git clone git@gitlab.mw.lab.eng.bos.redhat.com:jbossqe-eap/tests-transactions.git
get wildfly dist
mvn clean verify -Djboss.dist=__PATH_TO_DIST__ -Dtest=TxDifferentNodeCrashRecoveryTestCase#prepareHalt -DfailIfNoTests=false -Djbossts.noJTS
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Michael Musgrove
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move object store directory to the server2
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifiers on both servers are same)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11833:
--------------------------------------------
To further clarify what is going on here, let's differentiate between the calling proxy affinity and the result proxy affinity. In this example, a client makes a remote invocation on a server using its calling proxy. The server, in the process of processing the invocation, creates a SFSB on the server, and returns a proxy for that SFSB back to the caller. This is the result proxy. During this single invocation, both the caller proxy and the result proxy will have their affinities adjusted.
The adjustment to the caller proxy is made using the information gathered by invocation interceptors, the affinity parameters passed to the server, and the affinity changes returned from the server. The final adjustments are made in EJBClientInvocationContext.getResult() when the final settings for strong affinity and weak affinity are established. The purpose of this affinity adjustment is for correctly managing the behavior of SLSB load balancing and SFSB fail-over, both of which depend on affinities to constrain choice of the correct target node.
Th adjustment to result proxy is made during the marshaling and un-marshaling of the result from the server back to the client. Here, writeReplace() and readResiove() are used to replace the original affinity defined in the created proxy from Affinity.LOCAL to something else, where that something else depends only on the connection endpoints between client and server, as mentioned above.
It's important to keep these two aspects separated.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip, test-debug-log.txt
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-12317:
-------------------------------
Description:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (old and new node-identifiers on both servers are same)
was:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (node-identifier's "old" value are same as new one)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Michael Musgrove
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move object store directory to the server2
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifiers on both servers are same)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson reassigned WFLY-12317:
---------------------------------------
Assignee: Michael Musgrove (was: Thomas Jenkinson)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Michael Musgrove
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move object store directory to the server2
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (node-identifier's "old" value are same as new one)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-12317:
-------------------------------
Description:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (node-identifier's "old" value are same as new one)
was:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Hence the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (node-identifier's "old" value are same as new one)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Thomas Jenkinson
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move object store directory to the server2
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (node-identifier's "old" value are same as new one)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka updated WFLY-12317:
-------------------------------
Description:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Hence the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (node-identifier's "old" value are same as new one)
was:
We have following test scenario (3 servers) that fails:
# client call an EJB bean (where a transaction is started) on the server1
# the EJB sends JMS message to the server3 (broker)
# the EJB enlists dummy xa resource
# during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
# we move object store directory to the server2
# the server2 is expected to rollback whole transaction
Transaction is unfinished because server2 has not performed rollback.
{code:java}
prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
{code}
In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
I see in logs that TX's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Hence the server2 has not performed rollback.
See node_name
Server1:
{code:java}
2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
{code}
Server2:
{code:java}
2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
{code}
{code:java}
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
{code}
When I run the TS with
{code:java}
-Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
{code}
the test passes (node-identifier's "old" value are same as new one)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Thomas Jenkinson
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move object store directory to the server2
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Hence the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (node-identifier's "old" value are same as new one)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
- 1
- 0