[
https://jira.jboss.org/jira/browse/JBTM-611?page=com.atlassian.jira.plugi...
]
Andrew Dinn commented on JBTM-611:
----------------------------------
reaper check() method now checks for and pulls in pending TXs each
time round the main loop in order to ensure it does not process any
entries out of order. it also locks the queue when it dequeues the
first entry, ensuring that it shares a consistent view of what is
first with any inserting threads
reaper now includes pending TXs when computing transactions count and
timeouts count.
reaper inserts now check the timeouts and pending timeouts maps before
adding an element to detect duplicate adds. This is a guard against
badly implemented hash and equals methods since our code will never
add the same instance twice. Note that a deferred add (to the pending
queue) may succeed but later fail when the TX is added to the sorted
list. This is a guard against badly implemented compareTo
methods. Both of these could be dropped if the performance hit is too
large (we don't really need to care about users who break the reaper
by failing to implement equality or trichotomy).
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: Andrew Dinn
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