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
reopen).
On Nov 12, 2007, at 5:14 PM, Michael McCandless wrote:
"robert engels" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
