[
https://issues.apache.org/jira/browse/OAK-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666742#comment-15666742
]
Chetan Mehrotra commented on OAK-4935:
--------------------------------------
bq. about passing a different marker that would imply the refresh is outside of
the root (checkpoints are on the super root anyway) so it can be ignored?
Its more about this. This would allow all observer to skip processing the event
(though processing should be very fast for such change just that it adds to
queue). Currently this is done via ChangeCollectorProvider setting a ChangeSet
instance in CommitContext which is part of CommitInfo which records what all
changes have occurred in the commit associated with the given commit. So we can
possibly use same approach here.
For CP creation and release this should be safe to do
> support prefiltering of async index updates
> -------------------------------------------
>
> Key: OAK-4935
> URL: https://issues.apache.org/jira/browse/OAK-4935
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.5.12
> Reporter: Stefan Egli
> Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.14
>
>
> As pointed out
> [here|https://issues.apache.org/jira/browse/OAK-4924?focusedCommentId=15568308&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15568308]
> at the moment the AsyncIndexUpdate, via SegmentNodeStore.refreshHead passes
> null in the contentChanged call. This prevents prefiltering from being
> applied.
> [~chetanm] suggested to explicitly run the ChangeCollector ValidationProvider
> in the AsyncIndexUpdate.mergeWithConcurrencyCheck (see [comment
> here|https://issues.apache.org/jira/browse/OAK-4924?focusedCommentId=15568339&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15568339]).
> Alternatively the AsyncIndexUpdate.mergeWithConcurrencyCheck could provide an
> explicit ChangeSet representing empty sets for all (paths, names, types,
> properties), as really an index update shouldn't generate anything of
> interest for any jcr listener. Not sure if this is always 100% the case but
> it sounds like a bit of a waste of CPU to collect hidden paths (of the
> indices) in a ChangeSet which then anyway shouldn't be applicable to any
> listener. But yes, it would be somewhat of a violation of the general
> contract to have the ChangeSet represent all changes. Then again, we could
> argue that hidden paths aren't included.
> [~chetanm], wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
