Re: More IndexDeletionPolicy questions

2008-03-05 Thread Tim Brennan
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 single writer? Mike Tim Brennan wrote: The bigger

Re: More IndexDeletionPolicy questions

2008-03-05 Thread Tim Brennan
, 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! Mike Tim Brennan wrote: No, I have multiple readers

Re: More IndexDeletionPolicy questions

2008-03-04 Thread Tim Brennan
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

More IndexDeletionPolicy questions

2008-02-29 Thread Tim Brennan
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

IndexDeletionPolicy and IndexCommitPoint

2008-02-21 Thread Tim Brennan
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