[
https://issues.apache.org/jira/browse/LUCENE-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627824#comment-13627824
]
Shai Erera commented on LUCENE-3786:
------------------------------------
I reviewed again, and now that you switch to calling close() instead of
decRef(), I think the close() should be done via IOUtils.close, to avoid a
potential close failure (newReader.close()) and leave behind a dangling TR?
Also test() also has these 5 close() statements which can be folded into one
IOUtils. But that's just style.
bq. I don't like that cutting over to DTW would open up the thread hazard that
we fail to catch the replace
What I meant is that if instead of checking epoch on TR you check on DTW, you
won't (I think!) get into that hazard. That is: (1) reopen TR (2) check if
DTW.epoch is different than the one the manager was created with. The only
false positive in this case is that the TR might be valid (i.e. in between 1
and 2 a replaceTaxo was called), but I think that's ok to throw the exception,
since on the next refresh you'll fail anyway?
Anyway, I don't have any strong feelings about it. It is indeed safer to put it
on TR and let TR provide evidence "for itself". If you want to keep it, can you
make getEpoch public on both DTW and DTR, to be consistent.
> Create SearcherTaxoManager
> --------------------------
>
> Key: LUCENE-3786
> URL: https://issues.apache.org/jira/browse/LUCENE-3786
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/facet
> Reporter: Shai Erera
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 5.0, 4.3
>
> Attachments: LUCENE-3786-3x-nocommit.patch, LUCENE-3786.patch,
> LUCENE-3786.patch, LUCENE-3786.patch
>
>
> If an application wants to use an IndexSearcher and TaxonomyReader in a
> SearcherManager-like fashion, it cannot use a separate SearcherManager, and
> say a TaxonomyReaderManager, because the IndexSearcher and TaxoReader
> instances need to be in sync. That is, the IS-TR pair must match, or
> otherwise the category ordinals that are encoded in the search index might
> not match the ones in the taxonomy index.
> This can happen if someone reopens the IndexSearcher's IndexReader, but does
> not refresh the TaxonomyReader, and the category ordinals that exist in the
> reopened IndexReader are not yet visible to the TaxonomyReader instance.
> I'd like to create a SearcherTaxoManager (which is a ReferenceManager) which
> manages an IndexSearcher and TaxonomyReader pair. Then an application will
> call:
> {code}
> SearcherTaxoPair pair = manager.acquire();
> try {
> IndexSearcher searcher = pair.searcher;
> TaxonomyReader taxoReader = pair.taxoReader;
> // do something with them
> } finally {
> manager.release(pair);
> pair = null;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
