lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Updated] (LUCENE-2955) Add utitily class to manage NRT reopening
Date Thu, 09 Jun 2011 22:51:58 GMT


Michael McCandless updated LUCENE-2955:

    Attachment: LUCENE-2955.patch

OK, new patch, folding in Simon's & Chris's feedback (thanks!).

I pulled out the reopen thread into a separate class, so that one can
now instantiate NRTManager but do their own reopening (no bg reopen
thread).  So eg if you want to hijack indexing threads to do reopen,
you can.

But if you want to simply reopen on a periodic basis with the bg
thread, instantiate NRTManagerReopenThread, passing it the manager and
your max and min staleness.  Max staleness applies when no caller is
waiting for a specific indexing change; min applies when one is.

I didn't implement a ReopenStrategy... I think that should live
"above" this class.  But, I did add a WaitingListener so that such a
reopener reopener can be notified when someone is waiting for a
specific generation to be visible (NRTManagerReopenThread uses

> Add utitily class to manage NRT reopening
> -----------------------------------------
>                 Key: LUCENE-2955
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 3.3
>         Attachments: LUCENE-2955.patch, LUCENE-2955.patch, LUCENE-2955.patch
> I created a simple class, NRTManager, that tries to abstract away some
> of the reopen logic when using NRT readers.
> You give it your IW, tell it min and max nanoseconds staleness you can
> tolerate, and it privately runs a reopen thread to periodically reopen
> the searcher.
> It subsumes the SearcherManager from LIA2.  Besides running the reopen
> thread, it also adds the notion of a "generation" containing changes
> you've made.  So eg it has addDocument, returning a long.  You can
> then take that long value and pass it back to the getSearcher method
> and getSearcher will return a searcher that reflects the changes made
> in that generation.
> This gives your app the freedom to force "immediate" consistency (ie
> wait for the reopen) only for those searches that require it, like a
> verifier that adds a doc and then immediately searches for it, but
> also use "eventual consistency" for other searches.
> I want to also add support for the new "applyDeletions" option when
> pulling an NRT reader.
> Also, this is very new and I'm sure buggy -- the concurrency is either
> wrong over overly-locking.  But it's a start...

This message is automatically generated by JIRA.
For more information on JIRA, see:

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

View raw message