[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1028:
---------------------------------------
I understand, I was hoping that you could give me some idea how to find all these right tuples, so I can use the data in the objects to identify which rule patterns are causing the issue. In the mean time, I'll work up a sample set of rules for you to examine.
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-245) Drools sees a type as a package
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-245?page=com.atlassian.jira.plugin... ]
Petr Široký closed DROOLS-245.
------------------------------
Resolution: Cannot Reproduce
I wasn't able to reproduce this issue. There has been many fixes over the two years, so it is likely the issue was fixed by them. Please reopen in case you would still see the same error happening (and please attach executable reproducer in ideal case).
> Drools sees a type as a package
> --------------------------------
>
> Key: DROOLS-245
> URL: https://issues.jboss.org/browse/DROOLS-245
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Reporter: georg tornqvist
> Assignee: Petr Široký
>
> Hi,
> I want Drools to reason over an axis2 type, but the Drools compiler sees the type as a package, see error message below.
> Strictly speaking, the Drools compiler may be right. The type "Client" encapsulates a "Factory" class, making hierarchically speaking the class "Client" a package.
> Although I'm fairly new to Drools, I'm pretty sure that the behavior I'm experiencing is not right. The Drools version used in the WSO2BRS-2.0.0 is able to reason over the very same axis2 types.
> Error importing : 'nl.domain.www.schema.Client'
> Rule Compilation error : [Rule name='Your First Rule']
> io31/Rule_Your_First_Rule_16db2a632a4b4efd96dde4c6d6a55cdf.java (2:57) : Only a type can be imported.
> nl.domain.www.schema.Client resolves to a package
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1028:
-------------------------------------
Can you please attach a reproducer or at least give me an idea of our your rule are written? It's very likely that you found a bug but it's nearly impossible for me to find where the problem could be without having a chance to reproduce it.
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6015) Testing JDBC connection is causing it to be added
by Renann Prado (JIRA)
Renann Prado created WFLY-6015:
----------------------------------
Summary: Testing JDBC connection is causing it to be added
Key: WFLY-6015
URL: https://issues.jboss.org/browse/WFLY-6015
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.CR5
Environment: Mac OS X El Captain with latest update
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
MariaDB - with MariaDB JDBC driver deployed
Reporter: Renann Prado
Assignee: Jason Greene
Testing JDBC connection is causing it to be added.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1028:
---------------------------------------
A little more information regarding the right tuple creation mentioned above.
I set the memory on the jvm to 310mb to cause java heap dump files to be created. I have attached a screenshot (screenshot-1.png) that shows 2 different heap dump analyzer tools indicate there are over 1.2 million right tuples in memory now.
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1028:
----------------------------------
Component/s: core engine
(was: kie server)
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Edson Tirelli
> Attachments: screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1028:
----------------------------------
Attachment: screenshot-1.png
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Edson Tirelli
> Attachments: screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1028:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6011) Remote branch of a transaction gets rolled back incorrectly.
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6011?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-6011:
-------------------------------------
I have an update to the narayana tests that shows how you could achieve something like this. Note the parentDisconnected operation. It would be intended to be called by a server when it detects a remote connection has died.
> Remote branch of a transaction gets rolled back incorrectly.
> -------------------------------------------------------------
>
> Key: WFLY-6011
> URL: https://issues.jboss.org/browse/WFLY-6011
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Jason Greene
> Assignee: David Lloyd
>
> The use case is as follow:
> Client makes a call to a bean on server-1
> bean (server-1) inserts a row into table-1
> bean (server-1) calls to a bean on server-2
> bean (server-2) inserts a row into table-2
> bean (server-2) goes to sleep for 3 minutes
> periodic recovery (server-1) flags the remote branchof the transaction (on server-2) as in doubt and rolls it back.
> (server-1 log)
> {noformat}
> 11:53:37,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover no RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@322f7790, receiver=Remoting connection EJB receiver [connection=Remoting connection <2c1ab3f6>,channel=jboss.ejb,nodename=server2]}, transactionOriginNodeIdentifier='server1'} 1452599607985 === 1452599617991
> 11:53:37,991 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass.
> 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name >
> 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server1
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server2
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > exists in ObjectStore.
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Looking for 0:ffffc0a80164:-fa2e9db:5694e833:2c and /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA
> 11:53:37,993 INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name >
> {noformat}
> (server-2 log)
> {noformat}
> 11:53:37,997 TRACE [com.arjuna.ats.jta] (EJB default - 5) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
> 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::phase2Abort() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34
> 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort (XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >)
> 11:53:37,998 TRACE [com.arjuna.ats.jta] (EJB default - 5) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >, record id=0:ffffc0a80164:-41fcd6d0:5694e85a:3f
> 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Unlock: HeldByCurrentThread: Yes, Locked: Yes, HoldCount: 1, QueueLength: 0
> 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Owner: Thread[EJB default - 5,5,EJB default]
> 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort() result for action-id (0:ffffc0a80164:-41fcd6d0:5694e85a:34) on record id: (0:ffffc0a80164:-41fcd6d0:5694e85a:3f) is (TwoPhaseOutcome.FINISH_OK) node id: (server2)
> 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::updateState() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34
> 11:53:37,999 TRACE [com.arjuna.ats.jta] (EJB default - 5) SynchronizationImple.afterCompletion
> {noformat}
> bean (server-2) wake up
> bean (server-1) updates the row in table-1
> at this point the parent transaction gets committed without an error
> {noformat}
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1 result = true
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) TransactionReaper::remove ( BasicAction: 0:ffffc0a80164:-fa2e9db:5694e833:2c status: ActionStatus.COMMITTED )
> {noformat}
> client call ends
> When I look at the table in the database I see a row in table-1 but no row in table-2. I would expect to see both tables empty.
> When I switch to JTS and run the same use case it all works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months