Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42658B0E.4080905@dhlz.com>
Date: Wed, 20 Apr 2005 00:49:50 +0200
From: Daniel Herlitz <daniel@dhlz.com>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
MIME-Version: 1.0
To: java-user@lucene.apache.org
Subject: Re: Best way to purposely corrupt an index?
References: <200504192122.08102.mail@andy-roberts.net>
 <42658846.4010904@dhlz.com>
In-Reply-To: <42658846.4010904@dhlz.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hm well, I unconsciously extrapolated natural language into java syntax. 
Just in case, should be:

try: Build the index in a separate catalogue.
if all ok: remove ('rm') production index and move ('mv') newly built 
index to its place. Notify using app that it should reopen its IndexReader.

/D


I would suggest you simply do not create unusable indexes. :-)  Handle 
catch/throw/finally correctly and it should not present any problems.

Assume one app builds the index, another uses it:

try: Build the index in a separate catalogue.
finally: remove ('rm') production index and move ('mv') newly built 
index to its place. Notify using app that it should reopen its IndexReader.

This relies on UNIX file handling semantics. (Can't say a word about 
Windows). Don't know if this applies at all to our situation, but it 
works for us.


Daniel Herlitz wrote:

> I would suggest you simply do not create unusable indexes. :-)  Handle 
> catch/throw/finally correctly and it should not present any problems.
>
> Assume one app builds the index, another uses it:
>
> try: Build the index in a separate catalogue.
> finally: remove ('rm') production index and move ('mv') newly built 
> index to its place. Notify using app that it should reopen its 
> IndexReader.
>
> This relies on UNIX file handling semantics. (Can't say a word about 
> Windows). Don't know if this applies at all to our situation, but it 
> works for us.
>
> /D
>
> Andy Roberts wrote:
>
>> Hi,
>>
>> Seems like an odd request I'm sure. However, my application relies an 
>> index, and should the index become unusable for some unfortunate 
>> reason, I'd like my app to gracefully cope with this situation.
>>
>> Firstly, I need to know how to detect a broken index. Opening an 
>> IndexReader can potentially throw an IOException if a problem occurs, 
>> but presumably this will be thrown for other reasons, not just an 
>> unreadable index. Would the IndexReader.indexExists() be better?
>>
>> Secondly, to test how my code responds to broken indexes, I'd like to 
>> purposely break an index. Any suggestions, or will removing any file 
>> from the directory be sufficient?
>>
>> Many thanks,
>> Andy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>  
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org