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