You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Martijn Hendriks (JIRA)" <ji...@apache.org> on 2007/05/09 11:43:15 UTC
[jira] Created: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
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
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.
Re: [jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 9/18/07, Andrea K. <ak...@alteanet.it> wrote:
> Could I expect to have this patch included in an interim release like JR
> 1.3.2?
Sure!
BR,
Jukka Zitting
Re: [jira] Commented: (JCR-905) Clustering: race condition may
cause duplicate entries in search index
Posted by "Andrea K." <ak...@alteanet.it>.
Bien,
thanks again for your work.
Could I expect to have this patch included in an interim release like JR
1.3.2?
BR,
Andrea -
Marcel Reutegger wrote:
>
> Andrea K. wrote:
>> Do you think it is a safe patch to use in a production environment?
>
> yes, I think it is safe to apply the patch. it only adds some overhead to
> the
> indexing process.
>
> regards
> marcel
>
>
--
View this message in context: http://www.nabble.com/-jira--Created%3A-%28JCR-905%29-Clustering%3A-race-condition-may-cause-duplicate-entries-in-search-index-tf3714767.html#a12754122
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by Marcel Reutegger <ma...@gmx.net>.
Andrea K. wrote:
> Do you think it is a safe patch to use in a production environment?
yes, I think it is safe to apply the patch. it only adds some overhead to the
indexing process.
regards
marcel
Re: [jira] Commented: (JCR-905) Clustering: race condition may
cause duplicate entries in search index
Posted by "Andrea K." <ak...@alteanet.it>.
Hi,
some reindexing on a test cluster say that the patch seems to work
correctly.
I can't see any error, but I didn't tested it so deeply, just patched the
code and
reindexed whole repository on servers and a test client. Anyway, apparently
no double records.
First patch proposed worked also for me. No big difference noticed between
them, but, as I can see in JIRA comments, latest patch eliminates overheads
in non-clustered apps.
Please guide me to any other kind of test I can do (time permitted...).
Do you think it is a safe patch to use in a production environment?
Thanks a lot for your works...
Bye,
Andre -
--
View this message in context: http://www.nabble.com/-jira--Created%3A-%28JCR-905%29-Clustering%3A-race-condition-may-cause-duplicate-entries-in-search-index-tf3714767.html#a12752986
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Andrea,
yes, please do so. If you see that the problem is gone with the patch I will
commit it.
regards
marcel
Andrea K. wrote:
> Hi Marcel,
> I'm just trying your proposed patch on a cluster.
>
> If you want I can send you the resulting JR debug log and personal
> impressions.
>
> Thanks.
> Andrea -
>
>
> Marcel Reutegger wrote:
>> Andrea K. wrote:
>>> Hi all,
>>> i'm testing the "2 line patch" as suggested in
>>> (https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel).
>>>
>>> As I can see, no duplicated nodes exists with cluster configuration.
>>>
>>> What do you think aboout the patch proposed? Should it be used without
>>> any
>>> problem (other than a slow indexing tasks)?
>> the patch will probably work, but is not a good solution to the problem.
>> it adds
>> overhead even if jackrabbit is not clustered.
>>
>>
>> regards
>> marcel
>>
>>
>
Re: [jira] Commented: (JCR-905) Clustering: race condition may
cause duplicate entries in search index
Posted by "Andrea K." <ak...@alteanet.it>.
Hi Marcel,
I'm just trying your proposed patch on a cluster.
If you want I can send you the resulting JR debug log and personal
impressions.
Thanks.
Andrea -
Marcel Reutegger wrote:
>
> Andrea K. wrote:
>> Hi all,
>> i'm testing the "2 line patch" as suggested in
>> (https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel).
>>
>> As I can see, no duplicated nodes exists with cluster configuration.
>>
>> What do you think aboout the patch proposed? Should it be used without
>> any
>> problem (other than a slow indexing tasks)?
>
> the patch will probably work, but is not a good solution to the problem.
> it adds
> overhead even if jackrabbit is not clustered.
>
>
> regards
> marcel
>
>
--
View this message in context: http://www.nabble.com/-jira--Created%3A-%28JCR-905%29-Clustering%3A-race-condition-may-cause-duplicate-entries-in-search-index-tf3714767.html#a12679727
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by Marcel Reutegger <ma...@gmx.net>.
Andrea K. wrote:
> Hi all,
> i'm testing the "2 line patch" as suggested in
> (https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel).
>
> As I can see, no duplicated nodes exists with cluster configuration.
>
> What do you think aboout the patch proposed? Should it be used without any
> problem (other than a slow indexing tasks)?
the patch will probably work, but is not a good solution to the problem. it adds
overhead even if jackrabbit is not clustered.
regards
marcel
Re: [jira] Commented: (JCR-905) Clustering: race condition may
cause duplicate entries in search index
Posted by "Andrea K." <ak...@alteanet.it>.
Hi all,
i'm testing the "2 line patch" as suggested in
(https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel).
As I can see, no duplicated nodes exists with cluster configuration.
What do you think aboout the patch proposed? Should it be used without any
problem (other than a slow indexing tasks)?
It's very important for me to get a fix for this problem.
Please report your comments.
Thanks in advance.
JIRA jira@apache.org wrote:
>
>
> [
> 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.
>
>
>
--
View this message in context: http://www.nabble.com/-jira--Created%3A-%28JCR-905%29-Clustering%3A-race-condition-may-cause-duplicate-entries-in-search-index-tf3714767.html#a12521069
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511114 ]
Jukka Zitting commented on JCR-905:
-----------------------------------
Dominique/Marcel, do you see any potential regressions with this patch? I'm not confident enough to apply it in 1.3.1, but it sounds like it definitely should go in trunk before 1.4.
> 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.
[jira] Updated: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-905:
------------------------------
Affects Version/s: 1.2.1
1.2.2
1.2.3
1.3.1
Fix Version/s: (was: 1.4)
1.3.2
Merged to the 1.3 branch in revision 577835.
> 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.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1
> Reporter: Martijn Hendriks
> Fix For: 1.3.2
>
> Attachments: JCR-905.patch, log1.txt, log2.txt, SearchManager.patch
>
>
> 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.
[jira] Updated: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-905:
---------------------------------
Attachment: SearchManager.patch
Here's an alternative patch, which handles the possible duplicates earlier in the index process, where it is also possible to detect an external update. This avoids the overhead for Jackrabbit instance, which does not operate in a cluster.
Can someone with a cluster installation please test the patch and give feedback. I'll then commit the patch if it fixes the issue.
> 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, SearchManager.patch
>
>
> 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.
[jira] Updated: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martijn Hendriks updated JCR-905:
---------------------------------
Attachment: JCR-905.patch
We've found a one-line fix for this issue. The problem is that when the search index receives an event to add a node to the index, it does not take consider the persistent indices. The one-line fix is to first remove the node from the multi-index before adding it again: see attached patch.
> 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: 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.
[jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528043 ]
Martijn Hendriks commented on JCR-905:
--------------------------------------
I just tested Marcel's patch and it works fine. It's good to eliminate the overhead for non-clustered installations!
Best wishes,
Martijn
> 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, SearchManager.patch
>
>
> 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.
[jira] Resolved: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-905.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Applied patch in revision: 576813
Thank you all for testing.
> 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
> Fix For: 1.4
>
> Attachments: JCR-905.patch, log1.txt, log2.txt, SearchManager.patch
>
>
> 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.
[jira] Updated: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-905) Clustering: race condition may cause
duplicate entries in search index
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511401 ]
Marcel Reutegger commented on JCR-905:
--------------------------------------
This patch adds considerable overhead to the index process because for each added node the index has to first check if the node already exists. In lucene terms this means that lots of index readers and index writers are created and destroyed in a short period of time. The current code relies on the fact that the events passed to the query handler reflect a correct state change on the workspace. E.g. if an event says that a node is added, the index assumes that the node does not exist in the index.
I see two ways to fix this issue:
- The query handler does not automatically re-index the workspace, but rather re-plays the cluster-journal to get a valid index.
- The query handler needs to associate a journal revision with the current index state. When journal events are processed the query handler will ignore events from the 'past'.
I prefer option 2.
> 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.