August 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-597) Implement subordinate coordinator for WS-BA

by Andrew Dinn (JIRA)

Implement subordinate coordinator for WS-BA ------------------------------------------- Key: JBTM-597 URL: https://jira.jboss.org/jira/browse/JBTM-597 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.7.0 Reporter: Andrew Dinn Assignee: Andrew Dinn The WS-BA protocol implementation should allow propagated transactions to be coordinated by a subordinate coordinator as currently happens with WS-AT. BA-enabled web services should be allowed to access this functionality by installing a server side JaxWS handler as per the WS-AT subordinate implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-610) Restore mutex handling on LockManager

by Mark Little (JIRA)

Restore mutex handling on LockManager ------------------------------------- Key: JBTM-610 URL: https://jira.jboss.org/jira/browse/JBTM-610 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.8.0 It looks like someone tried to optimize the synchronizations around LockManager, probably for HP-MS performance tuning. Unfortunately they didn't fully understand the implications. Backing out to original approach until/unless performance becomes an issue again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
7
0 / 0

[JBoss JIRA] Created: (JBTM-598) load recovery manager properties at service startup

by Jonathan Halliday (JIRA)

load recovery manager properties at service startup --------------------------------------------------- Key: JBTM-598 URL: https://jira.jboss.org/jira/browse/JBTM-598 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration Affects Versions: 4.2.3.SP5 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.2.3.SP8, 4.2.3.CP06 During TransactionManagerService startup, some recovery manager properties are read from the arjPropertyManager by other parts of the system before the startup of the recovery manager, which is where their installation into the arjPropertyManager currently takes place. This timing issue causes the property values to be defaulted. The service startup should load the properties at an early stage to avoid this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-301) Failure to recover one XAResource in log fails to recover the rest

by Mark Little (JIRA)

Failure to recover one XAResource in log fails to recover the rest ------------------------------------------------------------------ Key: JBTM-301 URL: http://jira.jboss.com/jira/browse/JBTM-301 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, Recovery Reporter: Mark Little Assigned To: Mark Little Priority: Critical Fix For: 4.4 If we can't get a new XAResource from a XAResourceRecovery then restore_state on XAResourceRecord fails, which causes the activate on the entire log to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
8
0 / 0

[JBoss JIRA] Created: (JBTM-567) reaper tests are time sensitive

by Jonathan Halliday (JIRA)

reaper tests are time sensitive ------------------------------- Key: JBTM-567 URL: https://jira.jboss.org/jira/browse/JBTM-567 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing, Transaction Core Affects Versions: 4.6.1 Reporter: Jonathan Halliday Assignee: Andrew Dinn Fix For: 4.8.0 Reaper unit tests can fail intermittently due to timing issues. This happens when e.g. a test machine is under heavy load. The tests should be more robust against this to prevent spurious build failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBTM-614) Backport reaper performance tweaks

by Andrew Dinn (JIRA)

Backport reaper performance tweaks ---------------------------------- Key: JBTM-614 URL: https://jira.jboss.org/jira/browse/JBTM-614 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.2.3.CP05, 4.2.3.SP7 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.2.3.SP8, 4.2.3.CP06 All applicable performance tweaks made in JBTM-611 should be back-ported to the 4.2.3.SP branch. Not all these changes can easily be applied since the code bases differ. This extends the performance improvements made for JBTM-207. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-236) Timeout references microseconds for periodicity when it should be milliseconds

by Mark Little (JIRA)

Timeout references microseconds for periodicity when it should be milliseconds ------------------------------------------------------------------------------ Key: JBTM-236 URL: http://jira.jboss.com/jira/browse/JBTM-236 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JBTM-237) NORMAL mode for TransactionReaper sets checking period based on transaction timeout and not property

by Mark Little (JIRA)

NORMAL mode for TransactionReaper sets checking period based on transaction timeout and not property ---------------------------------------------------------------------------------------------------- Key: JBTM-237 URL: http://jira.jboss.com/jira/browse/JBTM-237 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little In the insert method the sleep period for the transaction reaper thread is continually modified to be based on the least timeout associated with the transaction added. This is fine for DYNAMIC mode, but is contrary to what NORMAL is supposed to do: scan based purely on the default scan timeout period specified in the configuration file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBTM-611) performance tune transaction reaper

by Jonathan Halliday (JIRA)

performance tune transaction reaper ----------------------------------- Key: JBTM-611 URL: https://jira.jboss.org/jira/browse/JBTM-611 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.7.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.8.0 In situations where a large number of tx are being created and destroyed concurrently, the TransactionReaper represents a potential bottleneck due to the necessary synchronization. For most worklolads this is insignificant as it is dominated by the objectstore I/O. However, for tx scenarios that don't write the store (1PC, local resources, etc) it's a potential problem, so it's worth tuning a bit. There are some things we can do to reduce the workload inside the synchronized scope. 1- ReaperElements are kept in a sorted list, by expiry time. To impose the total ordering required by SortedSet, items with the same expire time (to the nearest ms) are distinguished by Uid. This is an expensive comparison. Introduce a sequence number or other cheap (i.e. int) element to the sort order so as to lessen the comparison (i.e. set insert/remove) cost. 2 - When a new tx is inserted into the reaper queue, we can avoid waking the reaper and having it recalculate the sleep interval, provided the new tx is not at the head of the queue i.e. does not have an expire time earlier than the existing wakeup time. 3 - Some debug logging is performed in synchronized blocks. Whilst this should not be removed, we can ensure it correctly checks the log threshold configuration, as generating log output statements unnecessarily is expensive 4 - The transactions and timeouts collections are currently synchronized Collections. Since almost all access to them is guarded by a lock on the TransactionReaper instance, they could be replaced by unsynchronized versions with a little work. This may or may not be helpful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-609) TwoPhaseOutcome needs modifying

by Mark Little (JIRA)

TwoPhaseOutcome needs modifying ------------------------------- Key: JBTM-609 URL: https://jira.jboss.org/jira/browse/JBTM-609 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: future More outcomes possible since the early days of C++ Arjuna. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2009