[JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2209:
----------------------------------------
OK I have added a bit of asbestos to the fireguard ;-) and created 2 JMH benchmarks for comparing the use of Stack versus Deque in ThreadActionData. My findings are:
* with benchmark 1 Deque gives an 3.8% (5.8%) improvement using 1 (10) threads
* with benchmark 2 Deque gives an 3.8% (4.6%) improvement using 1 (10) threads
I ran each benchmark on my laptop for 5 mins (running each test twice using either 1 or 10 threads to do the work on my quad core laptop (with a 1s warmup). I watched the CPU usage to ensure that it was roughly constant (100% for the 1 thread test and about 400% for the 10 thread test).
I think this is good enough to accept the PR.
The actual benchmark is:
https://github.com/mmusgrov/performance/blob/JBTM-1453/narayana/ArjunaCor...
In more detail:
Benchmark 1: com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest.testCheckedAction: Start 10 AtomicActions and for each action add a synchronization and 5 child threads and then suspend the action. Then, for each action resume it, remove its child threads and commit it.
Benchmark 2: com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest.testThreadActionData: Start 2 AtomicActions and manipulate their action hierarchy using currentAction(), restoreActions, popAction and purgeActions
{quote}
Test 1 (Stack using 1 thread for 300s): 45423 ops/s
Test 1 (Stack using 10 threads for 300s): 108201 ops/s
Test 2 (Stack using 1 thread for 300s): 651056 ops/s
Test 2 (Stack using 10 threads for 300s): 1443719 ops/s
Test 1 (Deque using 1 thread for 300s): 47200 ops/s
Test 1 (Deque using 10 threads for 300s): 114613 ops/s
Test 2 (Deque using 1 thread for 300s): 676561 ops/s
Test 2 (Deque using 10 threads for 300s): 1511950 ops/s
{quote}
Note I cherry picked Jespers Deque implementation on master (5.0.4.Final-SNAPSHOT todays version) and for the Stack implementation I used 5.0.3.Final-SNAPSHOT (the one just before it was tagged).
> Use Deque for ThreadActionData
> ------------------------------
>
> Key: JBTM-2209
> URL: https://issues.jboss.org/browse/JBTM-2209
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: Transaction Core
> Reporter: Jesper Pedersen
> Assignee: Michael Musgrove
> Attachments: Test.java
>
>
> Note, there are other usages of java.util.Stack in the code base that could be changed as well
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2208) Removed unused method from ActionManager
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2208:
----------------------------------------
We cannot change the semantics of the getTimeAdded (by calling currentTimeMillis lazily or returning a fake value) since any user of this API method will be doing so because he wants to know when the action was added. I have marked the method as Depecated and will remove in a subsequent release.
> Removed unused method from ActionManager
> ----------------------------------------
>
> Key: JBTM-2208
> URL: https://issues.jboss.org/browse/JBTM-2208
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: Transaction Core
> Reporter: Jesper Pedersen
> Assignee: Michael Musgrove
>
> Removed unused method from ActionManager, and thereby a System.currentTimeMillis call
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2242:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Both PRs passed
> Misbehaving XAResources may delay deployments
> ---------------------------------------------
>
> Key: JBTM-2242
> URL: https://issues.jboss.org/browse/JBTM-2242
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Application Server Integration
> Affects Versions: 4.17.22, 5.0.2
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.23, 5.0.4
>
>
> Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers:
> XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2247.
-------------------------------
Resolution: Rejected
Hi Sergey,
I am going to close this issue and as Mark has already suggested, I too would recommend opening a support case for your issue.
With more detail it appears as though EJB is enlisting many XAResources with the same transaction. As Mike says, we maintain the list of duplicates for spec compliance reasons. Although the EJB usage is legal it may still be possible to optimize that aspect of the system to avoid duplicate registration. I believe it registers the XAR in order to propagate certain information to remote servers in the case where the application requires that behaviour. If you are not using multiple servers it may be possible that EJB would not require its XAR registering at all.
So I do not believe this to be a bug in JBTM, hence why I have to close the issue here.
I am sure your report will assist the support engineer responsible as it was very helpful to diagnose the issue so far.
Thanks again,
Tom
> Memory leak in TransactionImple
> -------------------------------
>
> Key: JBTM-2247
> URL: https://issues.jboss.org/browse/JBTM-2247
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 4.16.2
> Reporter: Sergey Shilin
> Assignee: Tom Jenkinson
> Priority: Critical
> Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG
>
>
> There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.
> HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2249) Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2249?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2249:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security
> -------------------------------------------------------------------------------
>
> Key: JBTM-2249
> URL: https://issues.jboss.org/browse/JBTM-2249
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Fix For: 5.0.4
>
>
> http://172.17.131.2/view/Status/job/narayana/631/
> {code}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build (server-provisioning) on project wildfly-blacktie-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip modules: Could not resolve module resource artifact ${org.apache.cxf:cxf-rt-ws-security?jandex} for feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip ->
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2249) Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2249?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-2249:
---------------------------------
It dues to the wildfly build-tools upgrade.
> Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security
> -------------------------------------------------------------------------------
>
> Key: JBTM-2249
> URL: https://issues.jboss.org/browse/JBTM-2249
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Fix For: 5.0.4
>
>
> http://172.17.131.2/view/Status/job/narayana/631/
> {code}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build (server-provisioning) on project wildfly-blacktie-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip modules: Could not resolve module resource artifact ${org.apache.cxf:cxf-rt-ws-security?jandex} for feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip ->
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months