3:18 a.m.
Paul Robinson created JBTM-1293:
-----------------------------------
Summary: ATBridgeTest#testSimple counter isn't incrimented
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 5sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:22 a.m.
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Paul Robinson commented on JBTM-1293:
-------------------------------------
I can confirm, the coordinator does send an async commit message to the participant:
{code}
@WebMethod(operationName = "CommitOperation", action =
"http://docs.oasis-open.org/ws-tx/wsat/2006/06/Commit")
@Oneway
@Action(input="http://docs.oasis-open.org/ws-tx/wsat/2006/06/Commit")
public void commitOperation(...
{code}
This simplest solution is to just add the delays.
ATBridgeTest#testSimple counter isn't incrimented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 5sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:24 a.m.
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Paul Robinson updated JBTM-1293:
--------------------------------
Description:
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
was:
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 5sec delay
between the two transactions. We should also look for other tests that may be affected.
ATBridgeTest#testSimple counter isn't incrimented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:57 a.m.
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Paul Robinson updated JBTM-1293:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/122
ATBridgeTest#testSimple counter isn't incrimented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:53 a.m.
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Paul Robinson updated JBTM-1293:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
ATBridgeTest#testSimple counter isn't incrimented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:22 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1293:
--------------------------------
Summary: ATBridgeTest#testSimple counter isn't incremented (was:
ATBridgeTest#testSimple counter isn't incrimented)
Git Pull Request: https://github.com/jbosstm/narayana/pull/122 (was:
https://github.com/jbosstm/narayana/pull/122)
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:22 a.m.
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Tom Jenkinson reopened JBTM-1293:
---------------------------------
Is this the same issue:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/26/?
ATBridgeTest#testSimple counter isn't incrimented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:20 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Paul Robinson commented on JBTM-1293:
-------------------------------------
Although, the commit is async, the coordinator waits 30s for the committed to come back.
Therefore it's 'usually' synchronous. See JBTM-1303.
To fix this now, we probably need to use Byteman as JBTM-1303 is non-trivial.
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:19 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Tom Jenkinson commented on JBTM-1293:
-------------------------------------
http://172.17.131.2/job/jbossts-narayana-java7/28/
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:09 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1293:
--------------------------------
Component/s: Testing
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Testing
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:12 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1293:
--------------------------------
Component/s: TXFramework
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Testing, TXFramework
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:44 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Tom Jenkinson commented on JBTM-1293:
-------------------------------------
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/47/
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Testing, TXFramework
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:22 a.m.
New subject: [JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
[
https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin....
]
Amos Feng commented on JBTM-1293:
---------------------------------
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/85/
{code}
Failed tests: testSimple(org.jboss.narayana.txframework.functional.ATBridgeTest):
expected:<1> but was:<0>
{code}
ATBridgeTest#testSimple counter isn't incremented
-------------------------------------------------
Key: JBTM-1293
URL: https://issues.jboss.org/browse/JBTM-1293
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Testing, TXFramework
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
{code}
@Test
public void testSimple() throws Exception
{
ut.begin();
client.incrementCounter(1);
ut.commit();
ut.begin();
int counter = client.getCounter();
ut.commit();
Assert.assertEquals(1, counter);
}
{code}
Even though the first transaction should have committed an update to the counter, it is
still set to zero in the second transaction.
This happens intermittently (once so far). It also happened on Beacon which is notorious
for test failures caused by things going slowly. I would suspect that the bridged JTA
transaction in the first transaction hasn't quite finished the commit when the second
transaction is begun.
If the WS-AT coordinator sends an async commit to the participants and an async committed
to the client, then this problem could happen if the client's 'committed' is
received before the participant's 'commit' message.
To verify this we need to check that the coordinator sends an async (@OneWay) commit
message to the participant. In which case the simplest solution is to add a 3sec delay
between the two transactions. We should also look for other tests that may be affected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4210
days inactive
4262
days old
jbossts-issues@lists.jboss.org
12 comments
3 participants
participants (3)
-
Amos Feng (JIRA) -
Paul Robinson (JIRA)
-
Tom Jenkinson (JIRA)