[
https://issues.apache.org/jira/browse/OAK-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734699#comment-14734699
]
Vikas Saurabh commented on OAK-3372:
------------------------------------
I think the easiest solution here can be that we don't collapse external events
until queue is full -- something like:
{code}
diff --git
a/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/BackgroundObserver.java
b/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/BackgroundObserver.java
index 2aef6e9..011db81 100644
---
a/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/BackgroundObserver.java
+++
b/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/BackgroundObserver.java
@@ -94,12 +94,6 @@ public class BackgroundObserver implements Observer,
Closeable {
}
/**
- * The content change that was last added to the queue.
- * Used to compact external changes.
- */
- private ContentChange last;
-
- /**
* Flag to indicate that some content changes were dropped because
* the queue was full.
*/
@@ -254,15 +248,6 @@ public class BackgroundObserver implements Observer,
Closeable {
checkState(!stopped);
checkNotNull(root);
- if (info == null && last != null && last.info == null) {
- // This is an external change. If the previous change was
- // also external, we can drop it from the queue (since external
- // changes in any case can cover multiple commits) to help
- // prevent the queue from filling up too fast.
- queue.remove(last);
- full = false;
- }
-
ContentChange change;
if (full) {
// If the queue is full, some commits have already been skipped
@@ -277,12 +262,6 @@ public class BackgroundObserver implements Observer,
Closeable {
// mark the queue as full if there wasn't enough space
full = !queue.offer(change);
- if (!full) {
- // Keep track of the last change added, so we can do the
- // compacting of external changes shown above.
- last = change;
- }
-
// Set the completion handler on the currently running task. Multiple
calls
// to onComplete are not a problem here since we always pass the same
value.
// Thus there is no question as to which of the handlers will
effectively run.
{code}
A possible concern here could be that we'd get too many external events -- but
then background reads already collapse multiple external revision reads. So,
this might not be an issue in general.
Another possible idea could be that we are able decompose tuple (A, C) into (A,
B) + (B, C) -- I think this would get tricky to manage though.
> Collapsing external events in BackgroundObserver even before queue is full
> leads to JournalEntry not getting used
> -----------------------------------------------------------------------------------------------------------------
>
> Key: OAK-3372
> URL: https://issues.apache.org/jira/browse/OAK-3372
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.3.5
> Reporter: Vikas Saurabh
> Labels: resilience
>
> BackgroundObserver currently merges external events if the last one in queue
> is also an external event. This leads to diff being done for a revision pair
> which is different from the ones pushed actively into cache during backgroud
> read (using JournalEntry) i.e. diff queries for {{diff("/a/b", rA, rC)}}
> while background read had pushed results of {{diff("/a/b", rA, rB)}} and
> {{diff("/a/b", rB, rC)}}.
> (cc [~mreutegg], [~egli], [~chetanm])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
