[
https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511697
]
Martijn Hendriks commented on JCR-905:
--------------------------------------
I already suspected that the proposed patch would give a significant
overhead... Option 2 sounds elegant, but bootstrapping it looks non-trivial to
me since the repository and the global revision can change during the
re-indexing.
> Clustering: race condition may cause duplicate entries in search index
> ----------------------------------------------------------------------
>
> Key: JCR-905
> URL: https://issues.apache.org/jira/browse/JCR-905
> Project: Jackrabbit
> Issue Type: Bug
> Components: clustering
> Affects Versions: 1.3
> Reporter: Martijn Hendriks
> Attachments: JCR-905.patch, log1.txt, log2.txt
>
>
> There seems to be a race condition that may cause duplicate search index
> entries. It is reproducible as follows (Jackrabbit 1.3):
> 1) Start clusternode 1 that just adds a single node of node type
> clustering:test.
> 2) Shutdown clusternode 1.
> 3) Start clusternode 2 with an empty search index.
> 4) Execute the query //element(*, clustering:test).
> 4) Print the result of the query (UUIDs of nodes in the result set).
> When I just run clusternode 2, then there is one node in the resultset, as
> expected. However, when I debug clusternode 2 and have a breakpoint (i.e., a
> pause of a few seconds at line 306 of RepositoryImpl.java - just before the
> clusternode is started), then the resultset contains two results, both with
> the same UUID.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
