[JBoss JIRA] (JBTM-1386) ATBridgeTest hangs during Deployment
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1386?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1386:
--------------------------------
Original Estimate: 2 days
Remaining Estimate: 2 days
> ATBridgeTest hangs during Deployment
> ------------------------------------
>
> Key: JBTM-1386
> URL: https://issues.jboss.org/browse/JBTM-1386
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Testing, TXFramework
> Environment: Job 124:
> Linux tenafly.buildnet.ncl.jboss.com 2.6.32-279.14.1.el6.i686 #1 SMP Tue Nov 6 21:05:14 UTC 2012 i686 i686 i386 GNU/Linux
> CentOS release 6.3 (Final)
> java version "1.6.0_37"
> Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
> Java HotSpot(TM) Client VM (build 20.12-b01, mixed mode, sharing)
> AS7 master on 10/12/2012
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Attachments: jboss.stacktrace, org.jboss.narayana.txframework.functional.ATBridgeTest-output.txt
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> http://172.17.131.2/job/jbossts-narayana-java6/121/
> http://172.17.131.2/job/jbossts-narayana-java6/124/
> Notice the following in the stack dump which looks very similar to [AS7-5946]:
> {code}
> "management-handler-thread - 3" prio=10 tid=0xa0661800 nid=0x282b in Object.wait() [0x9c669000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa626ae88> (a org.jboss.as.controller.ContainerStateMonitor)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> - locked <0xa626ae88> (a org.jboss.as.controller.ContainerStateMonitor)
> at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:452)
> at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:147)
> {code}
> Also, notice the last line of the server log:
> {code}
> [0m[0m16:08:52,111 INFO [org.jboss.as.arquillian] (MSC service thread 1-1) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."test.jar",unit=test.jar,tests=[org.jboss.narayana.txframework.functional.ATStatefullTest, org.jboss.narayana.txframework.functional.ATBridgeTest, org.jboss.narayana.txframework.functional.rest.at.simpleEJB
> {code}
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1311) Unify all XTS/localjunit tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1311?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1311:
--------------------------------
Original Estimate: 1 day (was: 4 hours)
Remaining Estimate: 1 day (was: 4 hours)
> Unify all XTS/localjunit tests
> -------------------------------
>
> Key: JBTM-1311
> URL: https://issues.jboss.org/browse/JBTM-1311
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 4.17.4, 5.0.0.M2
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> All the XTS/localjunit tests run with Arquillian and should have a consistent configuration. Therefore we should be able to put all the config in the XTS/localjunit/pom.xml. However, the crash recovery tests in particular have a there own properties and Arquillian config.
> Also, the test don't have a consistent arquillian.xml. We should try to make this consistent too
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1375) TXFramework Code Tidy
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1375?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1375:
--------------------------------
Original Estimate: 4 hours
Remaining Estimate: 4 hours
> TXFramework Code Tidy
> ---------------------
>
> Key: JBTM-1375
> URL: https://issues.jboss.org/browse/JBTM-1375
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Apply AS7 code style to .java
> format .xml
> Check all copyright headers present
> check no tabs
> Remover version numbers from pom
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1311) Unify all XTS/localjunit tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1311?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1311:
--------------------------------
Original Estimate: 4 hours
Remaining Estimate: 4 hours
> Unify all XTS/localjunit tests
> -------------------------------
>
> Key: JBTM-1311
> URL: https://issues.jboss.org/browse/JBTM-1311
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 4.17.4, 5.0.0.M2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> All the XTS/localjunit tests run with Arquillian and should have a consistent configuration. Therefore we should be able to put all the config in the XTS/localjunit/pom.xml. However, the crash recovery tests in particular have a there own properties and Arquillian config.
> Also, the test don't have a consistent arquillian.xml. We should try to make this consistent too
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1351) Narayana Quickstarts: consider putting dependencies in BOM as JDF quickstarts do
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1351?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1351:
--------------------------------
Original Estimate: 1 day
Remaining Estimate: 1 day
> Narayana Quickstarts: consider putting dependencies in BOM as JDF quickstarts do
> --------------------------------------------------------------------------------
>
> Key: JBTM-1351
> URL: https://issues.jboss.org/browse/JBTM-1351
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 5.0.0.M2
> Reporter: Ondřej Chaloupka
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 4.17.4, 5.0.0.M2
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Currently the quickstarts for Narayana project does not solve dependency management in some global way.
> Each directory contains one quickstart and it manages dependencies on its own what leads to situation that during compilation quickstarts as a whole project common libraries are downloaded several times (e.g. arquillian).
> There is idea of using JDF quickstart style of managing dependencies. They use BOMs where all dependencies are defined. Versions are defined in parent pom.xml.
> As inspiration could be used BOM from JDF:
> https://github.com/jboss-jdf/jboss-bom/blob/master/jboss-javaee-6.0-with-...
> It could be used this bom directly or just import it or do it in other way.
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1355) Merge XTS JUnit and Arquillian tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1355?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1355:
--------------------------------
Original Estimate: 4 hours
Remaining Estimate: 4 hours
> Merge XTS JUnit and Arquillian tests
> ------------------------------------
>
> Key: JBTM-1355
> URL: https://issues.jboss.org/browse/JBTM-1355
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Minor
> Labels: assign
> Fix For: 4.17.4, 5.0.0.M2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> When migrating the XTS tests to Arquillian, we wanted to make sure that the old tests where still functional whilst the Arquillian counterparts stabilized. As a result we now have two classes for each test. The Arquillian test delegates each @Test method to the corresponding @Test in the old suite.
> For example:
> We have the actual test in:
> ./XTS/localjunit/WSTX/src/main/java/com/arjuna/wst11/tests/arq/ba/MultiClose.java
> And then a Arquillian JUnit test which just calls the test methods above is here:
> ./XTS/localjunit/WSTX/src/test/java/com/arjuna/wst11/tests/arq/ba/MultiCloseTest.java
> To resolve this issue, we should remove the tests under './XTS/localjunit/WSTX/src/main/java' and merge the test methods into Arquillian test. At the end of this process "./XTS/localjunit/WSTX/src/main" should be empty (and thus removed).
> This applies to most, if not all suites under "./XTS/localjunit/".
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1293:
--------------------------------
Original Estimate: 3 days
Remaining Estimate: 3 days
> 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
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> 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
11 years, 11 months