Re: [jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
Hi, On 9/18/07, Andrea K. <[EMAIL PROTECTED]> 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
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
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
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.
[jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
[ 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.
Re: [jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
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
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
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
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 [EMAIL PROTECTED] 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
[ 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
[ 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.
[jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1254 ] 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.
