[JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
by Andrew Dinn (JIRA)
[ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.... ]
Andrew Dinn commented on JBTM-1766:
-----------------------------------
emma adds a field to all instrumented classes. It contains an array with entries for each method in the class. The entries are themselves arrays, each element of which contains a boolean which represents a simple path element in the method code. When a path is entered the array entry is set to true. That's how it marks coverage.
Why do you say this?
"Line 316 of org.jboss.stm.internal.proxy.LockManagerProxy therefore returns false"
I the lock manager saving and restoring state?
> STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1766
> URL: https://issues.jboss.org/browse/JBTM-1766
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: STM, Testing
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest) Time elapsed: 0.328 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?
--
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, 5 months
[JBoss JIRA] (JBTM-809) Replace transactional driver with ironjacamar
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-809?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on JBTM-809:
------------------------------------
Hi [~mauromol],
May I ask you to take a look at: https://community.jboss.org/thread/229203
Thanks,
Tom
> Replace transactional driver with ironjacamar
> ---------------------------------------------
>
> Key: JBTM-809
> URL: https://issues.jboss.org/browse/JBTM-809
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Resource Manager
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.Final
>
>
> Supporting the transactional driver source code on the face of it duplicates much effort with the IronJacamar team. Supporting IronJacamar for datasource access should be possible as this is the connection manager in the Application Server and it provides an embedded mode for use outside of the application server.
> There are several bugs open against transactional driver that will be resolved by completing this work.
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
> InitialContext initialContext = new InitialContext();
> UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
> DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL());
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
> May have to provide these both upfront.
--
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, 5 months
[JBoss JIRA] (JBTM-809) Replace transactional driver with ironjacamar
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-809?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-809:
-------------------------------
Forum Reference: https://community.jboss.org/thread/166568, https://community.jboss.org/thread/221392, https://community.jboss.org/thread/229203 (was: http://community.jboss.org/thread/166568, https://community.jboss.org/thread/221392?tstart=0)
> Replace transactional driver with ironjacamar
> ---------------------------------------------
>
> Key: JBTM-809
> URL: https://issues.jboss.org/browse/JBTM-809
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Resource Manager
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.Final
>
>
> Supporting the transactional driver source code on the face of it duplicates much effort with the IronJacamar team. Supporting IronJacamar for datasource access should be possible as this is the connection manager in the Application Server and it provides an embedded mode for use outside of the application server.
> There are several bugs open against transactional driver that will be resolved by completing this work.
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
> InitialContext initialContext = new InitialContext();
> UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
> DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL());
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
> May have to provide these both upfront.
--
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, 5 months
[JBoss JIRA] (JBTM-809) Replace transactional driver with ironjacamar
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-809?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-809:
-------------------------------
Description:
Supporting the transactional driver source code on the face of it duplicates much effort with the IronJacamar team. Supporting IronJacamar for datasource access should be possible as this is the connection manager in the Application Server and it provides an embedded mode for use outside of the application server.
There are several bugs open against transactional driver that will be resolved by completing this work.
The general approach would be along the lines of:
Startup
======
Embedded embedded = EmbeddedFactory.create();
embedded.startup();
embedded.deploy(new File("my-rar.rar").toURI().toURL());
embedded.deploy(new File("my-ds.xml").toURI().toURL());
In use
=====
InitialContext initialContext = new InitialContext();
UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
Shutdown
=======
embedded.undeploy(new File("my-ds.xml").toURI().toURL());
embedded.undeploy(new File("my-rar.rar").toURI().toURL());
embedded.shutdown(); // does not work - some threads don't stop
Problems?
=========
JCA transitive dependencies?
Accessing ds files from war?
Accessing rar from war?
May have to provide these both upfront.
was:
The general approach would be along the lines of:
Startup
======
Embedded embedded = EmbeddedFactory.create();
embedded.startup();
embedded.deploy(new File("my-rar.rar").toURI().toURL());
embedded.deploy(new File("my-ds.xml").toURI().toURL());
In use
=====
InitialContext initialContext = new InitialContext();
UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
Shutdown
=======
embedded.undeploy(new File("my-ds.xml").toURI().toURL());
embedded.undeploy(new File("my-rar.rar").toURI().toURL());
embedded.shutdown(); // does not work - some threads don't stop
Problems?
=========
JCA transitive dependencies?
Accessing ds files from war?
Accessing rar from war?
May have to provide these both upfront.
> Replace transactional driver with ironjacamar
> ---------------------------------------------
>
> Key: JBTM-809
> URL: https://issues.jboss.org/browse/JBTM-809
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Resource Manager
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.Final
>
>
> Supporting the transactional driver source code on the face of it duplicates much effort with the IronJacamar team. Supporting IronJacamar for datasource access should be possible as this is the connection manager in the Application Server and it provides an embedded mode for use outside of the application server.
> There are several bugs open against transactional driver that will be resolved by completing this work.
> The general approach would be along the lines of:
> Startup
> ======
> Embedded embedded = EmbeddedFactory.create();
> embedded.startup();
> embedded.deploy(new File("my-rar.rar").toURI().toURL());
> embedded.deploy(new File("my-ds.xml").toURI().toURL());
> In use
> =====
> InitialContext initialContext = new InitialContext();
> UserTransaction ut = (UserTransaction)initialContext.lookup("UserTransaction");
> DataSource dataSource = (DataSource)initialContext.lookup("java:/"+"TestDS");
> Shutdown
> =======
> embedded.undeploy(new File("my-ds.xml").toURI().toURL());
> embedded.undeploy(new File("my-rar.rar").toURI().toURL());
> embedded.shutdown(); // does not work - some threads don't stop
> Problems?
> =========
> JCA transitive dependencies?
> Accessing ds files from war?
> Accessing rar from war?
> May have to provide these both upfront.
--
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, 5 months
[JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1766:
-------------------------------------
OK, I think I have this one isolated a little in the debugger. Emma (I presume) is modifying the bytecode of the AtomicInteger class to add a field:
private static final boolean[][] org.jboss.stm.internal.types.AtomicIntegerImpl.$VRc
Line 316 of org.jboss.stm.internal.proxy.LockManagerProxy therefore returns false and cascades a decision which makes the LockManagerProxy think it has a conflict.
Is emma wrong to modify the bytecode (a relevant search shows VRc is added by EMMA: http://stackoverflow.com/questions/7389329/why-would-the-java-compiler-cr... I suspect other frameworks could do similar things with bytecode?
Is STM wrong to assume all state by default? Maybe the user should have to annotate state to save, rather than state not to save?
Is STM wrong to assume a conflict?
Why is it only this test that fails? What about AtomicArrayUnitTest, that one seems to work? I did a quick run of this in the debugger and freeState is called during the second call to set(). I haven't debugged that further to understand if that could be an issue too.
To run this in the debugger, make sure you have the following paths in your debugger:
1. The processed emma byte code must be first in the path so your IDE compiled files will be second. It will be in STM/target/generated-classes/emma/
2. The emma jar from ext/emma.jar
> STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1766
> URL: https://issues.jboss.org/browse/JBTM-1766
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: STM, Testing
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest) Time elapsed: 0.328 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?
--
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, 5 months
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1479:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
> Attachments: test-ds.xml, transaction.xml
>
> Original Estimate: 3 days
> Time Spent: 1 week, 2 days, 1 hour, 20 minutes
> Remaining Estimate: 0 minutes
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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, 5 months
[JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1766:
-------------------------------------
I also suspected a timing issue and that is how I found abort was being called as I put a thread.sleep before the abort and that got me looking at the output.
> STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1766
> URL: https://issues.jboss.org/browse/JBTM-1766
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: STM, Testing
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest) Time elapsed: 0.328 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?
--
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, 5 months
[JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
by Andrew Dinn (JIRA)
[ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.... ]
Andrew Dinn commented on JBTM-1766:
-----------------------------------
hmm, I was going to recommend that you fix the emma problem by upgrading to jacoco but I am not sure from what Tom is saying that the problem really is emma (not that upgrading is a bad idea -- emma is unsupported, which is why I originally forked and patched it and I don't really have time to continue investigating and fixing problems with it).
Anyway, if there is a lock conflict could that mean that there is a timing dependent problem here that running with emma is exposing? As opposed to emma transforming the code wrongly?
> STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1766
> URL: https://issues.jboss.org/browse/JBTM-1766
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: STM, Testing
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest) Time elapsed: 0.328 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?
--
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, 5 months
[JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1766:
--------------------------------
Attachment: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt
org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
> STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1766
> URL: https://issues.jboss.org/browse/JBTM-1766
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: STM, Testing
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest) Time elapsed: 0.328 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?
--
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, 5 months
[JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1766:
-------------------------------------
Hi Mark,
I have run this with log4j output and can confirm that the issue appears to occur prior to act.abort(); and the log file shows the "com.arjuna.ats.arjuna - BasicAction::Abort()" is still being printed out even with Emma on.
For some reason it looks like a lock conflict is causing a LockManager::freeState. I have attached a log with emma on and emma off that you can visually diff to see for some reason "LockManager::freeState()" is called (prior to abort by the look of it) in the "emma on" case.
Hope it helps,
Tom
> STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1766
> URL: https://issues.jboss.org/browse/JBTM-1766
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: STM, Testing
> Reporter: Tom Jenkinson
> Assignee: Mark Little
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest) Time elapsed: 0.328 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?
--
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, 5 months