[JBoss JIRA] (JBTM-2320) Implement getContainer on Container class
by Mark Little (JIRA)
Mark Little created JBTM-2320:
---------------------------------
Summary: Implement getContainer on Container class
Key: JBTM-2320
URL: https://issues.jboss.org/browse/JBTM-2320
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: STM
Affects Versions: 5.0.4
Reporter: Mark Little
Assignee: Mark Little
Currently it's a null-op ...
public static final Container<?> getContainer (Object proxy)
{
return null;
}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2319) Annotation-less STM
by Mark Little (JIRA)
Mark Little created JBTM-2319:
---------------------------------
Summary: Annotation-less STM
Key: JBTM-2319
URL: https://issues.jboss.org/browse/JBTM-2319
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: STM
Affects Versions: 5.0.4
Reporter: Mark Little
Assignee: Mark Little
Vert.x 3 works by auto-generating code for different language bindings to modules. Some of these languages don't support annotations. Hence the current STM implementation won't be applicable.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2318) Too verbose startup?
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2318?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2318:
-----------------------------------
I think we should first remove the bits before each INFO. None of that information seems important and is duplicated (pretty much) by the text that follows the INFO block anyway.
Then I like your idea of logging INFO (for what remains) only if the default ports are changed.
> Too verbose startup?
> --------------------
>
> Key: JBTM-2318
> URL: https://issues.jboss.org/browse/JBTM-2318
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Transaction Core
> Affects Versions: 5.0.4
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Priority: Minor
>
> At startup of the most basic example we see ...
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
> INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
> INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
> INFO: ARJUNA012170: TransactionStatusManager started on port 52185 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
> There's a separate conversation to be had about whether the INFO should be there (DEBUG maybe?) but ignoring those why do we print the other lines at all?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2318) Too verbose startup?
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2318?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2318:
-------------------------------------
Yeah, I haven't upgraded the logging for the component. The only thing I can think is that maybe the default used to be WARN or something?
>From looking at the log statements there looks to be three statements, its the way the log messages are formatted that is causing each of the statements to bridge two lines. The logging format looks to be the format generated by JDK logging rather than log4j so I guess this is in an IDE?
{code}
2014-12-18 16:30:49,755 [main] INFO (ats.arjuna :88 ) - ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 51214
2014-12-18 16:30:49,765 [main] INFO (ats.arjuna :327 ) - ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 51214
2014-12-18 16:30:49,765 [main] INFO (ats.arjuna :138 ) - ARJUNA012170: TransactionStatusManager started on port 51214 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
{code}
I am happy for those statements to move down to debug but the reason they are info is the default option seems to be to choose a random port so it might be the case then that people would all enable debug just to get at that. I can see why with multiple processes on the same machine why electing a port dynamically has some advantages but I know that WFLY at least configure a default of 4713. (4712 for recovery port). Why don't we use those defaults and only then log the statement at INFO if the user changes the port to 0?
> Too verbose startup?
> --------------------
>
> Key: JBTM-2318
> URL: https://issues.jboss.org/browse/JBTM-2318
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Transaction Core
> Affects Versions: 5.0.4
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Priority: Minor
>
> At startup of the most basic example we see ...
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
> INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
> INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
> INFO: ARJUNA012170: TransactionStatusManager started on port 52185 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
> There's a separate conversation to be had about whether the INFO should be there (DEBUG maybe?) but ignoring those why do we print the other lines at all?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2318) Too verbose startup?
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2318?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2318:
-----------------------------------
Agreed. Maybe create a separate JIRA for the tooling?
> Too verbose startup?
> --------------------
>
> Key: JBTM-2318
> URL: https://issues.jboss.org/browse/JBTM-2318
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Transaction Core
> Affects Versions: 5.0.4
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Priority: Minor
>
> At startup of the most basic example we see ...
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
> INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
> INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
> INFO: ARJUNA012170: TransactionStatusManager started on port 52185 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
> There's a separate conversation to be had about whether the INFO should be there (DEBUG maybe?) but ignoring those why do we print the other lines at all?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2318) Too verbose startup?
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2318?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2318:
----------------------------------------
I suspect it is historical. The messages were there when Tom ported the source from svn back in 2012 but I agree they do look like debug/trace messages to me.
Another separate conversation would be to instrument our environment beans so that these ports are available via the tooling.
> Too verbose startup?
> --------------------
>
> Key: JBTM-2318
> URL: https://issues.jboss.org/browse/JBTM-2318
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Transaction Core
> Affects Versions: 5.0.4
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Priority: Minor
>
> At startup of the most basic example we see ...
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
> INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
> INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 52185
> Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
> INFO: ARJUNA012170: TransactionStatusManager started on port 52185 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
> There's a separate conversation to be had about whether the INFO should be there (DEBUG maybe?) but ignoring those why do we print the other lines at all?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2318) Too verbose startup?
by Mark Little (JIRA)
Mark Little created JBTM-2318:
---------------------------------
Summary: Too verbose startup?
Key: JBTM-2318
URL: https://issues.jboss.org/browse/JBTM-2318
Project: JBoss Transaction Manager
Issue Type: Task
Components: Transaction Core
Affects Versions: 5.0.4
Reporter: Mark Little
Assignee: Tom Jenkinson
Priority: Minor
At startup of the most basic example we see ...
Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 52185
Dec 17, 2014 8:23:50 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 52185
Dec 17, 2014 8:23:50 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
INFO: ARJUNA012170: TransactionStatusManager started on port 52185 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
There's a separate conversation to be had about whether the INFO should be there (DEBUG maybe?) but ignoring those why do we print the other lines at all?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2301) PerformanceTest regression
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2301?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2301:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.0.5
(was: 5.x.y)
Resolution: Done
> PerformanceTest regression
> --------------------------
>
> Key: JBTM-2301
> URL: https://issues.jboss.org/browse/JBTM-2301
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Performance Testing
> Reporter: Gytis Trikleris
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.0.5
>
>
> http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/693/PROFIL...
> {code}
> -------------------------------------------------------------------------------
> Test set: io.narayana.perf.PerformanceTest
> -------------------------------------------------------------------------------
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.898 sec <<< FAILURE!
> regressionTest(io.narayana.perf.PerformanceTest) Time elapsed: 6.268 sec <<< FAILURE!
> junit.framework.AssertionFailedError: There should have been a perf regression
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at io.narayana.perf.PerformanceTest.regressionTest(PerformanceTest.java:296)
> {code}
> {code}
> Test Run: testTimeout (200 calls using 2 threads)
> ExecutionException exception: java.util.concurrent.BrokenBarrierException
> ExecutionException exception: java.util.concurrent.BrokenBarrierException
> testTimeout: 0.000000 calls / second (200 calls in 0 ms using 2 threads. 201 errors)
> Test Run: (100000 calls using 10 threads)
> TestPerformance for 100000!: 17164.435290 calls / second (total time: 5826 ms versus 46786 ms)
> Test Run: (1 calls using 1 threads)
> testSingleCall!: 1000.000000 calls / second (1 calls in 1 ms using 1 threads. 0 errors)
> Test Run: (10000 calls using 10 threads)
> perfTest!: 4268.032437 calls / second (10000 calls in 2343 ms using 10 threads. 0 errors)
> Test Run: (100 calls using 2 threads)
> java.lang.RuntimeException: Testing throw exception
> at io.narayana.perf.PerformanceTest$7.doWork(PerformanceTest.java:412)
> at io.narayana.perf.PerformanceTest$7.doWork(PerformanceTest.java:406)
> at io.narayana.perf.Measurement$1.call(Measurement.java:339)
> at io.narayana.perf.Measurement$1.call(Measurement.java:324)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> testCancelOnException!: 33333.333333 calls / second (100 calls in 3 ms using 2 threads. 20 errors)
> Test Run: io.narayana.perf.PerformanceTest_regressionTest (10000 calls using 10 threads)
> Test Run: io.narayana.perf.PerformanceTest_regressionTest (10000 calls using 10 threads)
> Test Run: (1000 calls using 10 threads)
> testAbortMeasurement2: 0.000000 calls / second (1000 calls in 0 ms using 10 threads. 11 errors)
> Test Warm Up: io.narayana.perf.PerformanceTest_readPerfArgsTest: (10 calls using 50 threads)
> Test Run: io.narayana.perf.PerformanceTest_readPerfArgsTest (1000000 calls using 50 threads)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBTM-2301) PerformanceTest regression
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2301?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2301:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/781
> PerformanceTest regression
> --------------------------
>
> Key: JBTM-2301
> URL: https://issues.jboss.org/browse/JBTM-2301
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Performance Testing
> Reporter: Gytis Trikleris
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.x.y
>
>
> http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/693/PROFIL...
> {code}
> -------------------------------------------------------------------------------
> Test set: io.narayana.perf.PerformanceTest
> -------------------------------------------------------------------------------
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.898 sec <<< FAILURE!
> regressionTest(io.narayana.perf.PerformanceTest) Time elapsed: 6.268 sec <<< FAILURE!
> junit.framework.AssertionFailedError: There should have been a perf regression
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at io.narayana.perf.PerformanceTest.regressionTest(PerformanceTest.java:296)
> {code}
> {code}
> Test Run: testTimeout (200 calls using 2 threads)
> ExecutionException exception: java.util.concurrent.BrokenBarrierException
> ExecutionException exception: java.util.concurrent.BrokenBarrierException
> testTimeout: 0.000000 calls / second (200 calls in 0 ms using 2 threads. 201 errors)
> Test Run: (100000 calls using 10 threads)
> TestPerformance for 100000!: 17164.435290 calls / second (total time: 5826 ms versus 46786 ms)
> Test Run: (1 calls using 1 threads)
> testSingleCall!: 1000.000000 calls / second (1 calls in 1 ms using 1 threads. 0 errors)
> Test Run: (10000 calls using 10 threads)
> perfTest!: 4268.032437 calls / second (10000 calls in 2343 ms using 10 threads. 0 errors)
> Test Run: (100 calls using 2 threads)
> java.lang.RuntimeException: Testing throw exception
> at io.narayana.perf.PerformanceTest$7.doWork(PerformanceTest.java:412)
> at io.narayana.perf.PerformanceTest$7.doWork(PerformanceTest.java:406)
> at io.narayana.perf.Measurement$1.call(Measurement.java:339)
> at io.narayana.perf.Measurement$1.call(Measurement.java:324)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> testCancelOnException!: 33333.333333 calls / second (100 calls in 3 ms using 2 threads. 20 errors)
> Test Run: io.narayana.perf.PerformanceTest_regressionTest (10000 calls using 10 threads)
> Test Run: io.narayana.perf.PerformanceTest_regressionTest (10000 calls using 10 threads)
> Test Run: (1000 calls using 10 threads)
> testAbortMeasurement2: 0.000000 calls / second (1000 calls in 0 ms using 10 threads. 11 errors)
> Test Warm Up: io.narayana.perf.PerformanceTest_readPerfArgsTest: (10 calls using 50 threads)
> Test Run: io.narayana.perf.PerformanceTest_readPerfArgsTest (1000000 calls using 50 threads)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months