[JBoss JIRA] (JBTM-2499) Race condition between BlackTie subsystem and Artemis starting up
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2499:
-----------------------------------
Summary: Race condition between BlackTie subsystem and Artemis starting up
Key: JBTM-2499
URL: https://issues.jboss.org/browse/JBTM-2499
Project: JBoss Transaction Manager
Issue Type: Bug
Components: BlackTie
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 5.next
Occasionally TcpServer tries to lookup ConnectionFactory before Artemis has started that component.
Solution is to delay the lookup until the subsystem is accessed which should work and at least will not bork the TcpServer thread and fail the entire subsystem until reboot.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2497) Update or remove references of HornetQ to Artemis
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2497?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2497:
----------------------------------------
The reference you refer to was only in the README.md which was correct when we were using old versions of the app server. Since moving to the later version all the BlackTie README.md files need updating so the Hornetq reference would disappear as a consequence of that update.
So this JIRA needs rejecting and the correct JIRA for the README updates is JBTM-2498
> Update or remove references of HornetQ to Artemis
> -------------------------------------------------
>
> Key: JBTM-2497
> URL: https://issues.jboss.org/browse/JBTM-2497
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: BlackTie, Demonstrator, Documentation
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.next
>
>
> There were reports of HornetQ still in at least the fooapp QS. We should try to remove references to the specific implementation unless necessary and in those cases use the correct name which is now Artemis.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2498:
--------------------------------------
Summary: Incomplete BlackTie quickstart documentation
Key: JBTM-2498
URL: https://issues.jboss.org/browse/JBTM-2498
Project: JBoss Transaction Manager
Issue Type: Bug
Components: BlackTie, Demonstrator, Documentation
Affects Versions: 5.2.2
Reporter: Michael Musgrove
Assignee: Amos Feng
The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly.
Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly.
My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 4 months
[JBoss JIRA] (JBTM-2497) Update or remove references of HornetQ to Artemis
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2497:
-----------------------------------
Summary: Update or remove references of HornetQ to Artemis
Key: JBTM-2497
URL: https://issues.jboss.org/browse/JBTM-2497
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: BlackTie, Demonstrator, Documentation
Reporter: Tom Jenkinson
Assignee: Amos Feng
Fix For: 5.next
There were reports of HornetQ still in at least the fooapp QS. We should try to remove references to the specific implementation unless necessary and in those cases use the correct name which is now Artemis.
--
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: Resolved (was: Pull Request Sent)
Resolution: Done
> 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-2234) out of memory when logging more messages than heap size (surefire issue)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2234:
-------------------------------------
Just a note that I think the logging is going to System.err so I really think it could be that the log implementation is not found and some default is being used....
> 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-2234) out of memory when logging more messages than heap size (surefire issue)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2234:
-------------------------------------
I had a look at this too and can't seem to influence the JacORB logger. Is it possible its not reading those settings because the logger is not set? I tried to add:
jacorb.log.loggerFactory=org.jboss.util.Log4jLoggerFactory
But that didn't seem to make a difference - maybe we don't have log4j in the classpath so some default not controllable logger is being used?
> 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