[JBoss JIRA] (JBTM-2488) Fix findbugs issues in rts modules
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2488?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2488:
-----------------------------------
Description:
The relevant issues can be seen by running:
bq. mvn clean install -DskipTests
bq. mvn site -DskipTests -Pfindbugs -f rts/pom.xml
was:
The relevant issues can be seen by running:
bq. mvn clean site -DskipTests -Pfindbugs -f rts/pom.xml
> Fix findbugs issues in rts modules
> ----------------------------------
>
> Key: JBTM-2488
> URL: https://issues.jboss.org/browse/JBTM-2488
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: REST
> Affects Versions: 5.2.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.later
>
>
> The relevant issues can be seen by running:
> bq. mvn clean install -DskipTests
> bq. mvn site -DskipTests -Pfindbugs -f rts/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2494) Product Comparison Benchmark failure
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2494?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2494:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/performance/pull/18
> Product Comparison Benchmark failure
> ------------------------------------
>
> Key: JBTM-2494
> URL: https://issues.jboss.org/browse/JBTM-2494
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.2.2
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> The benchmark CI job (narayana-benchmarks) fails when doing a product comparison test:
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203)
> at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.arjuna.ats.arjuna.coordinator.TxControl
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:94)
> at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:48)
> at io.narayana.perf.product.ProductComparison.testNarayana(ProductComparison.java:69)
> at io.narayana.perf.product.generated.ProductComparison_testNarayana.testNarayana_Throughput(ProductComparison_testNarayana.java:68)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2494) Product Comparison Benchmark failure
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2494:
--------------------------------------
Summary: Product Comparison Benchmark failure
Key: JBTM-2494
URL: https://issues.jboss.org/browse/JBTM-2494
Project: JBoss Transaction Manager
Issue Type: Bug
Affects Versions: 5.2.2
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.next
The benchmark CI job (narayana-benchmarks) fails when doing a product comparison test:
{code}
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203)
at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.arjuna.ats.arjuna.coordinator.TxControl
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:94)
at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:48)
at io.narayana.perf.product.ProductComparison.testNarayana(ProductComparison.java:69)
at io.narayana.perf.product.generated.ProductComparison_testNarayana.testNarayana_Throughput(ProductComparison_testNarayana.java:68)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2493) REST-AT integration API silently ignores non persistable participants
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2493:
--------------------------------------
Summary: REST-AT integration API silently ignores non persistable participants
Key: JBTM-2493
URL: https://issues.jboss.org/browse/JBTM-2493
Project: JBoss Transaction Manager
Issue Type: Bug
Components: REST
Affects Versions: 5.2.2
Reporter: Michael Musgrove
Assignee: Gytis Trikleris
The RESTAT integration API Participant interface is serialized during commit processing (in the method org.jboss.narayana.rest.integration.RecoveryManager#persistParticipantInformation) but the interface does not document this responsibility. The javadoc should say something like:
{code}
* Participant implementations must be implement either {@link java.io.Serializable} or {@link PersistableParticipant}
}
Secondly, during commit processing RecoveryManager#persistParticipantInformation needs to throw an exception if the participant cannot be written to the object store. At the moment it just writes a TRACE message.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2103) ORB-less JTS
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2103?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2103:
--------------------------------
Fix Version/s: 6.later
(was: 5.later)
> ORB-less JTS
> ------------
>
> Key: JBTM-2103
> URL: https://issues.jboss.org/browse/JBTM-2103
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTS
> Affects Versions: 5.0.0
> Reporter: Mark Little
> Assignee: Michael Musgrove
> Fix For: 6.later
>
>
> At some point in the future there's a good chance that the ORB requirement will be removed from EE entirely. If that happens we need to be able to react and ensure that the JTS continues to work because it’s the most complete distributed transaction implementation that we possess. Now there are two ways to do that:
> (i) we ship our own ORB, either JacORB or something else, say.
> (ii) we remove the dependency on CORBA entirely.
> Whilst (i) is a good short term option, I think we need to look at (ii). An old in-house TM that JBoss had which Narayana replaced had a JTS implementation which supported CORBA and JBoss Remoting (I think it was Remoting). Ultimately what we need is a high performance distributed transactions implementation and JTS is it today but it has a dependency on CORBA that we need to try to remove and yet keep most of the non-ORB generated code/dependencies.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-1699) Changes to the transaction SPI
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1699?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1699:
--------------------------------
Fix Version/s: 5.later
(was: 6.later)
> Changes to the transaction SPI
> ------------------------------
>
> Key: JBTM-1699
> URL: https://issues.jboss.org/browse/JBTM-1699
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Application Server Integration
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.later
>
> Original Estimate: 1 week, 3 days
> Remaining Estimate: 1 week, 3 days
>
> wildfly is using a number of our internal com.arjuna interfaces which we would like to resolve by providing the same functionality in the transactions SPI.
> Additionally the current SPI contains a number of unused classes which need removing.
> I have created https://github.com/jbosstm/jboss-transaction-spi to manage the changes. To avoid any potential confusion and to make it clear who is responsible for the SPI we will be changing the package names.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue)
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2234:
----------------------------------------
./build.sh -f ArjunaJTS/jts/pom.xml -Dtest=com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2
but you don't need to duplicate it since the issue is that the logger stores the messages in memory and only dumps them to a file at the end of the test. So you just need to reduce the JacORB logging level from INFO to just WARN and to verify the fix check that the log file does not contain any INFO messages.
> out of memory when logging more messages than heap size (surefire issue)
> ------------------------------------------------------------------------
>
> Key: JBTM-2234
> URL: https://issues.jboss.org/browse/JBTM-2234
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Performance Testing
> Affects Versions: 5.0.2
> Environment: JTS testing
> Reporter: Michael Musgrove
> Assignee: Amos Feng
> Priority: Optional
> Fix For: 5.next
>
>
> Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished.
> In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-1854) Hornetq failures in CI test suite on JDKORB
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1854:
-------------------------------------
Upped to Major as we are now targetting JDKORB
> Hornetq failures in CI test suite on JDKORB
> -------------------------------------------
>
> Key: JBTM-1854
> URL: https://issues.jboss.org/browse/JBTM-1854
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Affects Versions: 5.0.0.M3
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
> Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz
>
>
> The first CI job link includes:
> CurrentTests01_Test036
> jtsremote JTSRemote_ImplicitPropagationTest
> crashrecovery02_2 CrashRecovery02_2 - all of them
> crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10
> crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them)
> The second CI job link includes:
> JTSRemote_ImplicitPropagationTest failure
> CrashRecovery02_2_Test46 hang
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months