Stefan Egli commented on OAK-4916:

One way to do this would be to make the {{BackgroundObserver}} a 
{{FilteringAwareObserver}} such that it could get the 'skip' signal from the 
upstream, new '{{FilteringObserver}}'. It would be another variant to what 
Chetan's composition pattern, however the BackgroundObserver would still have 
to maintain about the same logic in {{contentChanged}} wrt skipped changes as 
now: the goal of prefiltering is to shrink the queue of the BackgroundObserver 
and for that we do have to make some adaptions there. Surely there are other 
variants than what I came up with, but I doubt it's possible without any change 
in the BackgroundObserver.

I'll work on a next iteration based on these 2 feedbacks, Thx!

> Add support for excluding commits to BackgroundObserver
> -------------------------------------------------------
>                 Key: OAK-4916
>                 URL: https://issues.apache.org/jira/browse/OAK-4916
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: core
>    Affects Versions: 1.5.11
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>             Fix For: 1.6
>         Attachments: OAK-4916.patch
> As part of pre-filtering commits it would be useful to have support in the 
> BackgroundObserver (in general) that would allow to exclude certain commits 
> from being added to the (BackgroundObserver's) queue, thus keeping the queue 
> smaller. The actual filtering is up to subclasses.
> The suggested implementation is as follows:
> * a new method {{isExcluded}} is introduced which represents a subclass hook 
> for filtering
> * excluded commits are not added to the queue
> * when multiple commits are excluded subsequently, this is collapsed
> * the first non-excluded commit (ContentChange) added to the queue is marked 
> with the last non-excluded root state as the 'previous root'
> * downstream Observers are notified of the exclusion of a commit via a 
> special CommitInfo {{NOOP_CHANGE}}: this instructs it to exclude this change 
> while at the same time 'fast-forwarding' the root state to the new one.
> ** this extra token is one way of solving the problem that 
> {{Observer.contentChanged}} represents a diff between two states but does not 
> transport the 'from' state explicitly - that is implicitly taken from the 
> previous call to {{contentChanged}}. Thus using such a gap token 
> ({{NOOP_CHANGE}}) seems to be the only way to instruct Observers to skip a 
> change.
> To repeat: whoever extends BackgroundObserver with filtering must be aware of 
> the new {{NOOP_CHANGE}} token. Anyone not doing filtering will not get any 
> {{NOOP_CHANGE}} tokens though.

This message was sent by Atlassian JIRA

Reply via email to