[
https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15374979#comment-15374979
]
Stefan Egli commented on OAK-4522:
----------------------------------
a stacktrace to illustrate the hard-to-find deadlock:
stack 1:
{code}
"sling-oak-observation-14" prio=5 tid=0x00007fc6de820000 nid=0xc607 waiting on
condition [0x000000011521a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000782578af0> (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore.merge(SegmentNodeStore.java:294)
...
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
...
at SlowListener.onEvent(SlowListener.java:65)
{code}
stack 2 (with a modified CommitRateLimiter that waits until queue drops below
threshold):
{code}
"qtp1011101703-240" prio=5 tid=0x00007fc6dbf49800 nid=0x9517 in Object.wait()
[0x0000000113079000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007821b6cf0> (a
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiter)
at
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiter.delay(CommitRateLimiter.java:327)
- locked <0x00000007821b6cf0> (a
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiter)
at
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiter.processCommit(CommitRateLimiter.java:309)
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.prepare(SegmentNodeStore.java:551)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.optimisticMerge(SegmentNodeStore.java:582)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.execute(SegmentNodeStore.java:638)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore.merge(SegmentNodeStore.java:297)
...
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
{code}
> Improve CommitRateLimiter to optionally block some commits
> ----------------------------------------------------------
>
> Key: OAK-4522
> URL: https://issues.apache.org/jira/browse/OAK-4522
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
>
> The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently
> block them, and delays even those commits that are part of handling events.
> Because of that, the queue can still get full, and possibly delaying commits
> while handling events can make the situation even worse.
> In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is
> JCR-2746.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
