Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <9387330.1178721795452.JavaMail.jira@brutus>
Date: Wed, 9 May 2007 07:43:15 -0700 (PDT)
From: "Martijn Hendriks (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-905) Clustering: race condition may cause
 duplicate entries in search index
In-Reply-To: <9745772.1178703795457.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martijn Hendriks updated JCR-905:
---------------------------------

    Attachment: log2.txt
                log1.txt

I think that the issue is caused by the fact that a Document for the node is created in two different indices as a result of the pause in scenario 2. Consider the attached log snippets. log1.txt shows scenario 1: everything is written to the volatile index. log2.txt shows what happens after a pause of a few seconds: the volatile index with the entry for node A (that has been generated by the index initialization) is written to disk, after which another Document containing node A is added to a new volatile index (as a result of an event that is generated by the cluster synchronization).

(Please note that I added a custom debug statement to MultiIndex$AddNode).

> 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: core
>    Affects Versions: 1.3
>            Reporter: Martijn Hendriks
>         Attachments: 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.