[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15587982#comment-15587982 ] Thomas Mueller commented on OAK-4522: - http://svn.apache.org/r1765547 (fix test case, take 2) > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.5.12 > > Attachments: OAK-4522-b.patch, OAK-4522-c.patch, OAK-4522.patch > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571155#comment-15571155 ] Thomas Mueller commented on OAK-4522: - http://svn.apache.org/r1764611 (fix test case) Actually the test case was "broken" before the above changes: it was relying on thread timing. Now the test uses an implementation detail of the CommitRateLimiter, which is also slightly bad, but I don't see an alternative. Also, the test is now faster. > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.5.12 > > Attachments: OAK-4522-b.patch, OAK-4522-c.patch, OAK-4522.patch > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551573#comment-15551573 ] Thomas Mueller commented on OAK-4522: - http://svn.apache.org/r1763550 > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.5.12 > > Attachments: OAK-4522-b.patch, OAK-4522-c.patch, OAK-4522.patch > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548855#comment-15548855 ] Thomas Mueller commented on OAK-4522: - > this patch only works with documentMk > revisit the nature of the CommitRateLimiter being a CommitHook > OAK-4122 Yes. I think that's a limitation we can live with at the moment. If we need to support Tar storage, more changes would be needed, which would be harder to backport (if backporting is needed). And I'm not aware of problems when using the Tar storage. > high-water-mark/low-water-mark as definition as to when you start/end blocking I think it would make the code more complicated, while not providing an additional feature. The current patch is to just ensure the CommitRateLimiter doesn't shoot itself in the foot. It's not designed to be fully optimized for performance. > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > Attachments: OAK-4522-b.patch, OAK-4522-c.patch, OAK-4522.patch > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420808#comment-15420808 ] Stefan Egli commented on OAK-4522: -- [~tmueller], did a review of [^OAK-4522-b.patch], looks good to me (didnt test it, only read 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > Attachments: OAK-4522-b.patch, OAK-4522.patch > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15415031#comment-15415031 ] Thomas Mueller commented on OAK-4522: - I just noticed it (sometimes?) breaks the CommitRateLimiterTest > Some nit picking: please set the threads interrupt flag upon catching > InterruptedException. Sure. > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > Attachments: OAK-4522-b.patch, OAK-4522.patch > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[
https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413635#comment-15413635
]
Michael Dürig commented on OAK-4522:
Some nit picking: please set the threads interrupt flag upon catching
{{InterruptedException}}.
> 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
> Components: jcr
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Labels: observation
> Fix For: 1.6
>
> Attachments: OAK-4522-b.patch, OAK-4522.patch
>
>
> 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399412#comment-15399412 ] Thomas Mueller commented on OAK-4522: - One problem of the current behavior, to throw an exception "System is busy" if the queue is full: if the observation listeners save multiple changes. In this case an exception could be thrown, even thought regular commits are stopped. That makes the behavior of the commit rate limiter somewhat random (sometimes commits are delayed, and sometimes an exception is thrown), based on pure luck. I would rather keep behavior deterministic by default, and pause until the queue is smaller. I understand it might be desirable to throw an exception for "some" commits, but I don't think we currently have a way to decide which ones are OK to reject and which ones are not. Therefore, I think it makes sense to disable the exception "System is busy" by default. > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399342#comment-15399342 ] Thomas Mueller commented on OAK-4522: - [~egli]'s patch uses a boolean to mark a thread non-blocking. Right now this should work fine, because the ChangeProcessor is non-reentrant (never called within a ChangeProcessor). However to make this future-proof, I think it's more save to use an integer (level) instead, and then use increment and decrement accordingly. And decrement before calling runningMonitor.leave(), in case that method throws an exception. > 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 > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[
https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399239#comment-15399239
]
Thomas Mueller commented on OAK-4522:
-
The patch from [~egli] looks good. It might be a bit problematic to use a loop,
if there are hundreds of observation listeners:
{noformat}
for (Double value : registeredQueueFillRatios.values()) {
maxFillRatio = Math.max(maxFillRatio, value);
}
{noformat}
But then, I guess we loop elsewhere as well on the list of BackgroundObservers,
so it might not be a real problem.
Instead of "threadNonBlocking.remove()" I would probably use
"threadNonBlocking.set(Boolean.FALSE)": it should be slightly faster, and is
not a class memory leak because it's a Boolean.
> 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
> Components: jcr
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Labels: observation
> Fix For: 1.6
>
>
> 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397550#comment-15397550 ] Thomas Mueller commented on OAK-4522: - The CommitRateLimiter currently only gets informed about added entries (when the queue grows), but not about removed entries (when the queue shrinks). That means once the commit rate limiter blocks commits, in the (unusual but possible) case that no new entries are added to the queue, it would never un-block. Support for removing events on removing entries is available in the second patch of OAK-4543. > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15395791#comment-15395791 ] Thomas Mueller commented on OAK-4522: - In general I will try to find a simple solution, but test it well. I'm not sure if OAK-4122 is simple, specially if this issue should be addressed as well. I will check if adding the delay loop in MutableRoot.commit is better than using a CommitHook (so the delay happens outside the lock). Also, I think that using a delay time (milliseconds) is not needed. Instead, just delay until the queue is smaller. I think that's simpler (no formula is needed) and will basically have the same effect. > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382335#comment-15382335 ] Michael Dürig commented on OAK-4522: I think to come up with a proper "commit rate limiter" we need to be able to control commits in a more sophisticated way than we are doing it in the current implementation. See OAK-4122 for initial ideas. > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[
https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15375147#comment-15375147
]
Stefan Egli commented on OAK-4522:
--
FYI: Added a 'prototype' to an oak fork
[here|https://github.com/stefan-egli/jackrabbit-oak/commit/40003909fd8c6e46d2016384acdb57744ad8be50]
that:
* adjusts delays on both queue growing and shrinking (by introducing {{added}}
/ {{removed}} to {{BackgroundObserver}})
* takes the real max of all queues (the current CommitRateLimiter is
non-deterministic there, as multiple listeners that are above the
DELAY_THRESHOLD overwrite each other's delay)
* introduces a PAUSE_THRESHOLD that pauses 'indefinitely', ie until queue
shrinks back to DELAY_THRESHOLD
* uses a ThreadLocal to mark listeners' threads as "not to block"
> 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[
https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=0x7fc6de82 nid=0xc607 waiting on
condition [0x00011521a000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000782578af0> (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=0x7fc6dbf49800 nid=0x9517 in Object.wait()
[0x000113079000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0007821b6cf0> (a
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiter)
at
org.apache.jackrabbit.oak.plugins.observation.CommitRateLimiter.delay(CommitRateLimiter.java:327)
- locked <0x0007821b6cf0> (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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374972#comment-15374972 ] Stefan Egli commented on OAK-4522: -- there is one more aspect to take into account here: it's fine that the CommitRateLimiter tries to not block any listener's doing a commit. However, that is not enough: there is a [synchronized in SegmentNodeStore.merge()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStore.java#L294] which always hits, in any session.save(). Now if a listener does a session.save() while the CommitRateLimiter is delaying, it would still negatively prevent the listener from continuing. Unless doing any session.save() within a listener is prohibited (which I doubt it is, nor can be), the only solution is to try to *not* apply that synchronized for listeners too. If you don't - and we'd implement a schema where the CommitRateLimiter would *indefinitely block* until the queue comes back below a low-water mark, for example - you would have a *hard to find deadlock*. At which point it looks like applying the CommitRateLimiter as part of a CommitHook seems to become a problematic design choice. (Based on tests it looks like this type of 'hard to find deadlock' situation only applies to SegmentNodeStore, but still.) /cc [~chetanm], [~catholicon], [~mduerig], [~mreutegg] > 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)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355408#comment-15355408 ] Stefan Egli commented on OAK-4522: -- yes, and from this I conclude that you can't have a hard limit on observation queues - or at least that's making the situation more difficult. As we agree one shouldn't block the listeners, as they would help reducing the queues. But then, what if such a listener does a few commits that would result in a queue overflow? Hence I think having a hard limit is difficult and perhaps should not be applied for listeners, but only for 'normal' clients. > 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)
