[JBoss JIRA] (DROOLS-4361) Salience assignment behaviour is different when SequentialMaxPriority is set
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-4361:
------------------------------------
Summary: Salience assignment behaviour is different when SequentialMaxPriority is set
Key: DROOLS-4361
URL: https://issues.jboss.org/browse/DROOLS-4361
Project: Drools
Issue Type: Bug
Components: decision tables
Reporter: Hiroko Miura
Assignee: Mario Fusco
In Spreadsheet decision tables, RuleSet property SequentialMaxPriority and SequentialMinPriority are for controlling the salience number range of Rules generated from Decision Tables.
https://access.redhat.com/documentation/en-us/red_hat_decision_manager/7....
By setting Sequential=true without SequentialMaxPriority and SequentialMinPriority, the salience starts with 65535 and it's decremented one by one through all rules across multiple RuleTables.
On the other hand, by setting Sequential=true WITH SequentialMaxPriority,
every RuleTables starts with value specified by SequentialMaxPriority as salience.
i.e. first rule of each RuleTebles has same salience if there are multiple RuleTables.
In other words, when SequentialMaxPriority is set, start value of salience is reset per RuleTables, but this is unexpected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (DROOLS-4360) Salience assignment behaviour is different when SequentialMaxPriority is set
by Mario Fusco (Jira)
Mario Fusco created DROOLS-4360:
-----------------------------------
Summary: Salience assignment behaviour is different when SequentialMaxPriority is set
Key: DROOLS-4360
URL: https://issues.jboss.org/browse/DROOLS-4360
Project: Drools
Issue Type: Bug
Components: decision tables
Reporter: Mario Fusco
Assignee: Mario Fusco
In Spreadsheet decision tables, RuleSet property SequentialMaxPriority and SequentialMinPriority are for controlling the salience number range of Rules generated from Decision Tables.
https://access.redhat.com/documentation/en-us/red_hat_decision_manager/7....
By setting Sequential=true without SequentialMaxPriority and SequentialMinPriority, the salience starts with 65535 and it's decremented one by one through all rules across multiple RuleTables.
On the other hand, by setting Sequential=true WITH SequentialMaxPriority,
every RuleTables starts with value specified by SequentialMaxPriority as salience.
i.e. first rule of each RuleTebles has same salience if there are multiple RuleTables.
In other words, when SequentialMaxPriority is set, start value of salience is reset per RuleTables, but this is unexpected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (DROOLS-4358) line separators in CONDITION column in spreadsheet are escaped
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4358?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4358:
--------------------------------
Tester: Tibor Zimanyi
Story Points: 3
Sprint: 2019 Week 29-31
> line separators in CONDITION column in spreadsheet are escaped
> ---------------------------------------------------------------
>
> Key: DROOLS-4358
> URL: https://issues.jboss.org/browse/DROOLS-4358
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.24.0.Final
> Reporter: Hiroko Miura
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Attachments: multilinesInConditionTest.zip
>
>
> If there are several lines in a cell of CONDITION(LHS), line separators are escaped, and results in build failure.
> Output from SpredSheetCompiler:
> {noformat}
> rule "multiple lines in action_12"
> when
> $fact:Person(name == "John",\nage >= 20)
> then
> ...
> end
> {noformat}
> Error when building:
> {noformat}
> java.lang.AssertionError: [7,30]: [ERR 101] Line 7:30 no viable alternative at input '\' in rule "multiple lines in action_12"
> [0,0]: Parser returned a null Package
> {noformat}
> Escaping should be done only for literal String?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
Alessio Soldano updated WFLY-11943:
-----------------------------------
Fix Version/s: 18.0.0.Beta1
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
> Labels: affects-model
> Fix For: 18.0.0.Beta1
>
>
> Provide statistics on REST endpoints in the jaxrs subsystem.
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (WFLY-12291) SaslException: Authentication failed when XA Recovery tries to call remote server
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12291?page=com.atlassian.jira.plugin... ]
Flavia Rainone updated WFLY-12291:
----------------------------------
Fix Version/s: 18.0.0.Beta1
> SaslException: Authentication failed when XA Recovery tries to call remote server
> ---------------------------------------------------------------------------------
>
> Key: WFLY-12291
> URL: https://issues.jboss.org/browse/WFLY-12291
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Critical
> Fix For: 18.0.0.Beta1
>
>
> This is caused by how the current AuthenticationContext is captured when wildfly-transaction-client tries to do transaction recovery. It essentially calls ElytronXmlParser.parseAuthenticationClientConfiguration(), which calls org.wildfly.client.config.ClientConfiguration#getInstance(), which only looks for wildfly-config in various locations.
> Also see DefaultAuthenticationContextProvider
> {code}
> 13:30:06,851 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.2.GA (WildFly Core 6.0.14.Final-redhat-00001) started in 3798ms - Started 308 of 528 services (319 services are lazy, passive or on-demand)
> 13:30:46,524 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:201)
> at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:203)
> at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:199)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:622)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:214)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:159)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:444)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> 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:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:587)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:553)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:82)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:55)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:499)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:445)
> at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:52)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
> ... 8 more
> 13:31:16,537 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:726)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:507)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:258)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[JBoss JIRA] (WFLY-12307) The build-legacy module does not build correctly
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12307?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFLY-12307.
-------------------------------------
Resolution: Rejected
If nothing is broken let's not change the properties. The people who use these things know how to turn them on so we should not break them.
We want to get rid of these in the next year anyway.
> The build-legacy module does not build correctly
> ------------------------------------------------
>
> Key: WFLY-12307
> URL: https://issues.jboss.org/browse/WFLY-12307
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{build-legacy}} module requires both the {{legacy-build}} and {{legacy-release}} profiles to be activated. This should be reduced to the {{legacy-release}} profile as there should be no need to have just the build executed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 12 months
[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:
# node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
# server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
# server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
# server3 is running
# 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 server1 object store directory to the server2
# server2 is started
# 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:
# node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
# server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
# server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
# server3 is running
# 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
# server2 is started
# 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)
> 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:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # 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 server1 object store directory to the server2
> # server2 is started
> # 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