delete-on-last-close semantics. Ie, if
>
> the deletion of the file, and the held-open file handles, happen
> through a single NFS client, then it emulates delete-on-last-close
> semantics for you, by creating those .nfsXXX files on the server.
>
> Test to be sure though
r own
> DeletionPolicy.
>
> So presumably you have readers on different machines accessing the
> index over NFS, and then one machine that does the writing to that
> index? How so you plan to get which commit point each of these
> readers is currently using back to the singl
The bigger picture here is NFS-safety. When I run a search, I hand off the
search results to another thread so that they can be processed as necessary --
in particular so that they can be JOINed with a SQL DB -- but I don't want to
completely lock the index from writes while doing a bunch of SQ
Is there a direct way to ask an IndexReader what segment it is pointing at?
That would make implementing custom deletion policies a LOT easier.
It seems like it should be pretty simple -- keep a list of open IndexReaders,
track what Segment files they're pointing to, and in onCommit don't delet
When implementing a custom IndexDeletionPolicy, is it sufficient to just use
the segments filename (returned by IndexCommitPoint.getSegmentsFilename()) to
compare CommitPoints to see if they are equal?
I've looked at the code in SnapshotDeletionPolicy and it works by keeping a
pointer to the sn
