[
https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
