On Wed, Aug 31, 2011 at 3:16 PM, Dennis van der Laan <[email protected]> wrote: > Ian, others, > > As with many 'bugs' that have a workaround, this bug has been lying > around for about a year now. We still have the problem that the > cluster-nodes have different lucene indexes. At first, we thought this > happened over time. Recently we made a copy of our production database > and used it with 4 new cluster nodes (we cleared the journal table and > the local revisions table, first). We started them all, completely > clean, at which point all nodes started to build the lucene index. > Without making any changes to the contents, we see different results for > jackrabbit search queries on these 4 cluster nodes. So it seems the > lucene indexes might differ more over time, but could differ right from > the start. > > Does anybody have a clue how this could happen? Are we missing something?
I'm wondering what you mean with the statement: "different results for jackrabbit search queries". Could you perhaps show some of those queries? This could also be related to your indexing configuration. I asume you do not have an index when starting one of the cluster nodes? BTW which version of Jackrabbit are you experiencing this with? > > TIA > Dennis > > On 29-9-2010 12:37, Ian Boston wrote: >> On 29 Sep 2010, at 11:33, Dennis van der Laan wrote: >> >>> From your reply I >>> understand that this should not be the case with Lucene, is it? >> >> Every JournalRecord should have been replayed on every machine (at some time >> later if the JVM was down). That *should* ensure that all documents are >> indexed on all machines. >> Sounds like this is not happening in your environment. >> >> Ian >> > > > -- > Dennis van der Laan, MSc > Centre for Information Technology > University of Groningen > > -- Amsterdam - Oosteinde 11, 1017 WT Amsterdam Boston - 1 Broadway, Cambridge, MA 02142 US +1 877 414 4776 (toll free) Europe +31(0)20 522 4466 www.onehippo.com
