[
https://issues.apache.org/jira/browse/OAK-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506601#comment-15506601
]
Stefan Egli commented on OAK-4759:
----------------------------------
Regarding {{ConsolidatedChanges}}: I was wondering if we could not separate out
the 'ignores commitInfo' part and introduce a similar, perhaps called
{{IgnoresCommitInfo}} marker interface (point 2 from [suggestion on
list|http://markmail.org/thread/3blnp3lmsc24nbea]): any listener flagged with
that would set the {{ignoresEventInfo}} flag on the JackrabbitEventFilter and
it would essentially always get {{null}} as the CommitInfo.
That would of course allow further optimizations under the hood. Eg in your
case if a listener had both {{IgnoresCommitInfo}} and {{ConsolidatedChanges}}
set, it would allow a queueless change processor...
> Queueless change processor
> --------------------------
>
> Key: OAK-4759
> URL: https://issues.apache.org/jira/browse/OAK-4759
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk, jcr
> Reporter: Marcel Reutegger
> Labels: observation
> Fix For: 1.6
>
> Attachments: OAK-4759.patch, OAK-4759.patch, jackrabbit-api.patch,
> jackrabbit-api.patch
>
>
> The initial proposal for this improvement was:
> {quote}
> Change processing for listeners that are only interested in external
> events could be simplified because there is no commit info for
> external changes. The basic idea is that the node store implementation
> may be able to optimize batch processing of multiple external changes
> and does not need to process each external change individually. The
> DocumentNodeStore would use the journal to identify external changes
> and need to come up with a way to ignore overlapping local changes.
> With this new feature, expensive listeners that process local as well
> as external events could be split into two separate listeners, each
> optimized for the type of changes.
> {quote}
> Later the proposal was changed in a more general queueless change processor.
> See first comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
