]
Tom Jenkinson commented on WFLY-11343:
--------------------------------------
[~kabirkhan] the reason it would be different would be because it would be a semphore and
not a reentrant lock. As the comment suggests when either a reaper times out the
transaction or the transaction is propagated over a transport medium that uses a thread
pool then different threads can end up calling the cancel that don't own the lock.
I was just transferring the suggestion from Stuart, EJB timer code is not my specialism
either.
Lock is not released when JTS is enabled and a timer is cancelled
inside a transaction
--------------------------------------------------------------------------------------
Key: WFLY-11343
URL:
https://issues.jboss.org/browse/WFLY-11343
Project: WildFly
Issue Type: Bug
Components: EJB
Environment: EAP 6.4.18
Reporter: Shaun Appleton
Assignee: Tom Jenkinson
Priority: Major
Description of problem:
Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled
the lock won't be released correctly . This code is the problem:
https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f...
Basically it holds the timer lock until the transaction completes, and then attempts to
release it in afterCompletion. The problem is that when JTS is enabled afterCompletion
will be called by a seperate thread, which can't call unlock as it is not the owner.
A simple fix could be to just change the lock to a semaphore, so that the other thread
can release it.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1. Start a JTA/JTS tx and call an EJB timer inside it
2. Make the transaction timeout
3. Capture a thread dump and see a thread like below (0a0818b80 is locked object)
---------------------------------------------------------------------------------------------------------
"Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52
bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition
[0x00007f520ac97000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000a0818b80> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- <0x00000000ea1f4c48> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
---------------------------------------------------------------------------------------------------------
Actual results:
Lock being held forever
Expected results:
Lock getting released