lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <>
Subject Re: [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Mon, 12 Nov 2007 23:25:29 GMT
That is not true - at least it didn't use to be.  if there were  
readers open the files/segments would not be deleted. they would be  
deleted at next open.

The "purge criteria" was based on the next "commit" sets. To make  
this work, and be able to roll back or open a previous "version", you  
need to keep the segments around.

The commit "in flight" cannot (SHOULD NOT) be deleting segments if  
they are in use.  That a caller could issue a reopen call means there  
are segments in use by definition (or they would have nothing to  

On Nov 12, 2007, at 5:14 PM, Michael McCandless wrote:

> "robert engels" <> wrote:
>> But merging segments doesn't delete the old, it only creates new,
>> unless the segments meet the "purge old criteria".
> What's the "purge old criteria"?
> Normally a segment merge once committed immediately deletes the
> segments it had just merged.
>> A reopen() is supposed to open the latest version in the directory
>> by definition, so this seems rather a remote possibility.
> Well, if a commit is in-flight then likely the reopen will hit an
> exception and then retry.  This is the same as a normal open.
>> If it occurs due to low system resources (meaning that during a
>> reopen some expected segments were already deleted, throw an
>> StaleIndexException) and the client can reissue the reopen() call
>> (similar to if it could not get the write lock).
> I'm not sure what you mean by "low system resources".  Missing some
> files because they were deleted by a commit in process isn't a low
> system resources sort of situation.
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message