[
https://issues.apache.org/jira/browse/JCR-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729185#comment-14729185
]
Unico Hommes commented on JCR-3905:
-----------------------------------
It appears that creating the initial index and then checking pending journal
changes has a big and complicated history. Please see JCR-3162 for more
information.
> Journal sync after full re-index does not save journal revision
> ---------------------------------------------------------------
>
> Key: JCR-3905
> URL: https://issues.apache.org/jira/browse/JCR-3905
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering, indexing, jackrabbit-core
> Affects Versions: 2.8.1
> Environment: SQL persistence store
> Reporter: Philip Wasson
> Fix For: 2.10.2
>
>
> In org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit, if it
> discovers that the index is empty, it creates an initial index and then calls
> checkPendingJournalChanges(). That method reads all the new journal records
> (all at once, which is separate bug JCR-2483) and applies them. Since it is
> now caught up, it should save the revision number that it is up to, but it
> appears not to. As far as I can tell, this means that when the next journal
> sync occurs, it will re-fetch and re-process all the records it just
> processed.
> Also, it's not clear why it bothers to process the journal at this stage
> anyway, instead of letting it happen at the next journal sync.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
