You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2016/11/28 06:10:58 UTC

[jira] [Comment Edited] (OAK-5101) Enable prefiltering for external changes

    [ https://issues.apache.org/jira/browse/OAK-5101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701048#comment-15701048 ] 

Chetan Mehrotra edited comment on OAK-5101 at 11/28/16 6:10 AM:
----------------------------------------------------------------

[initial patch|^OAK-5101-v1.diff] for the same

Now a {{ChangeSetBuilder}} would be managed by a {{JournalEntry}} and and any change done in DocumentNodeStore would be added to it from CommitQueue#done call. Then upon background write the resulting ChangeSet would be written as part of JournalEntry (attr {{_cs}}). Note that changeSet would not be be added for branch commits

On read side when {{JournalEntry#fillExternalChanges}} is called from backgroundRead then a ChangeSetBuilder would be passed and would be filled from various JournalEntry read for that read. 

*Points to note*
# Missing ChangeSet from CommitInfo -  if any commit is done without any {{ChangeSet}} info present then no {{ChangeSet}} would be added to JournalEntry and upon read {{ChangeSetBuilder}} would be set to overflow mode. This should not happen in practice though as all interactions with NodeStore (JCR, AsyncIndexUpdate) now have {{ChangeSet}} attached to {{CommitInfo}}
* Upgrade - In upgrade case existing {{JournalEntry}} would not have {{ChangeSet}} set and thus resulting merged {{ChangeSet}} would be set to overflow

*Open Questions*
* Q1 - What should be defaults for {{ChangeSetBuilder}} {{maxItems}} and {{maxPathDepth}} limits. Right now its hardcoded to 50, 9. 
** Should we expose it via OSGi
* Q2 - Threadsafety - Current implementation *assumes* that writes to {{ChangeSetBuilder}} are single threaded. Should we still mark {{ChangeSetBuilder#add(ChangeSet)}} method as synchronized
** While individual commits - ChangeSet being added in {{ChangeSetBuilder}} in JournalEntry are done via CommitQueue so should be single threaded
** While background read - Here also ChangeSetBuilder gets updated but again in single threaded manner

[~mreutegg] [~egli] Please review


was (Author: chetanm):
[initial patch|^OAK-5101-v1.diff] for the same

Now a {{ChangeSetBuilder}} would be managed by a {{JournalEntry}} and and any change done in DocumentNodeStore would be added to it from CommitQueue#done call. Then upon background write the resulting ChangeSet would be written as part of JournalEntry (attr {{_cs}}). Note that changeSet would not be be added for branch commits

On read side when {{JournalEntry#fillExternalChanges}} is called from backgroundRead then a ChangeSetBuilder would be passed and would be filled from various JournalEntry read for that read. 

*Points to note*
# Missing ChangeSet from CommitInfo -  if any commit is done without any {{ChangeSet}} info present then no {{ChangeSet}} would be added to JournalEntry and upon read {{ChangeSetBuilder}} would be set to overflow mode. This should not happen in practice though as all interactions with NodeStore (JCR, AsyncIndexUpdate) now have {{ChangeSet}} attached to {{CommitInfo}]
* Upgrade - In upgrade case existing {{JournalEntry}} would not have {{ChangeSet}} set and thus resulting merged {{ChangeSet}} would be set to overflow

*Open Questions*
* Q1 - What should be defaults for {{ChangeSetBuilder}} {{maxItems}} and {{maxPathDepth}} limits. Right now its hardcoded to 50, 9. 
** Should we expose it via OSGi
* Q2 - Threadsafety - Current implementation *assumes* that writes to {{ChangeSetBuilder}} are single threaded. Should we still mark {{ChangeSetBuilder#add(ChangeSet)}} method as synchronized
** While individual commits - ChangeSet being added in {{ChangeSetBuilder}} in JournalEntry are done via CommitQueue so should be single threaded
** While background read - Here also ChangeSetBuilder gets updated but again in single threaded manner

[~mreutegg] [~egli] Please review

> Enable prefiltering for external changes
> ----------------------------------------
>
>                 Key: OAK-5101
>                 URL: https://issues.apache.org/jira/browse/OAK-5101
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, documentmk
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>             Fix For: 1.6
>
>         Attachments: OAK-5101-v1.diff
>
>
> With OAK-4796 its possible to prefilter an event change and avoid performing the diff if it can be determined that there is nothing of interest for the given listener. Currently this works for local changes.
> We should extend this support for external changes as those are more expensive to compute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)