Return-Path: 
 <users-return-3569-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org>
Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org
Received: (qmail 15246 invoked from network); 6 Jun 2007 03:08:35 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 6 Jun 2007 03:08:35 -0000
Received: (qmail 69181 invoked by uid 500); 6 Jun 2007 03:08:39 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 68835 invoked by uid 500); 6 Jun 2007 03:08:38 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:users@jackrabbit.apache.org>
List-Id: <users.jackrabbit.apache.org>
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 68823 invoked by uid 99); 6 Jun 2007 03:08:38 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2007 20:08:38 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [72.46.168.10] (HELO mail.maven.net) (72.46.168.10)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2007 20:08:32 -0700
Received: from [192.168.1.103] ([66.30.196.77]) by mail.maven.net with
 Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 5 Jun 2007 23:10:44 -0400
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <55AA2814-55F1-4EB4-92A7-9962288B6FF5@maven.net>
References: <BE74ECCE-C550-4ACD-8478-51D51F4C5884@maven.net>
 <4663D5DC.6070003@gmx.net> <55AA2814-55F1-4EB4-92A7-9962288B6FF5@maven.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4CE418B8-7D65-402A-82C7-A25B28649547@maven.net>
Content-Transfer-Encoding: 7bit
From: Noah Vihinen <nvihinen@maven.net>
Subject: Re: Removing Index
Date: Tue, 5 Jun 2007 23:08:07 -0400
To: users@jackrabbit.apache.org
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 06 Jun 2007 03:10:44.0115 (UTC)
 FILETIME=[455A5E30:01C7A7E8]
X-Virus-Checked: Checked by ClamAV on apache.org

Opened https://issues.apache.org/jira/browse/JCR-964 as this seems to  
be a blocker for us, until we can figure out how to rebuild an index  
from information in our DB.

On Jun 5, 2007, at 7:21 AM, Noah Vihinen wrote:

> OK, that makes sense.  However my main question is how do I recover  
> from a corrupt search index?  The automatic repair that seems to  
> kick in on a restart notifies me that the index cannot be  
> repaired.  It seems like a DB backup is not enough, and I also have  
> to back up my file-based search indexes.  This seems bad, as it  
> will be nearly impossible to take these two backup snapshots of two  
> persistent stores in the same state.
>
> On Jun 4, 2007, at 5:05 AM, Marcel Reutegger wrote:
>
>> Hi Noah,
>>
>> Noah Vihinen wrote:
>>> We've been running into issues with our jackrabbit index on  
>>> forced shutdowns.  On restarts, we end up getting errors like the  
>>> following:
>>> Error indexing root node:
>>> java.io.IOException: Error indexing root node:  
>>> b5d9c4a1-07d5-471e-9fc9-e9a2fbd6ae48
>>>         at  
>>> org.apache.jackrabbit.core.query.lucene.MultiIndex.<init> 
>>> (MultiIndex.java:313)         at  
>>> org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit 
>>> (SearchIndex.java:295)         at  
>>> org.apache.jackrabbit.core.query.AbstractQueryHandler.init 
>>> (AbstractQueryHandler.java:44)
>> [...]
>>> We attempted to get around this issue by simply deleted the index  
>>> of the repository (on the particular machine in a cluster) and  
>>> restarted with no luck.  In the end, the only thing that seems to  
>>> work is to copy the index directory from one of the other  
>>> functional machines in our cluster, followed by a restart.
>>> This seems like a really ugly way of getting around this issue.   
>>> Is there something obvious we're doing wrong.  Shouldn't it be  
>>> possible to add a machine to a cluster with no pre-existing  
>>> index?  What are we missing?
>>
>> My guess is, that this happens because content is changed while  
>> the new cluster node indexes (traverses) the workspace.
>>
>> Might be related to: http://issues.apache.org/jira/browse/JCR-931
>>
>> regards
>>  marcel
>