[
https://issues.apache.org/jira/browse/LUCENE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869253#action_12869253
]
Shay Banon commented on LUCENE-2468:
------------------------------------
bq. With the perf fix we are doing here, the problem (not correctly
"seeing" deletes on a reopened reader) is isolated to
CachingWrapperFilter/CachingSpanFilter, right?
Yes, but, this means that ConstantScoreQuery should basically not be cached
when using NRT (even with using IndexReader as key...), because of the
excessive readers created. With the one that is deletion aware, you can cache
it based on the cache key.
bq. I think this would be a good change - it would make eviction immediate
instead of just when GC gets around to pruning the WeakHashMap. Can you open a
separate issue and maybe work out a patch?
Sure, I will do it.
> reopen on NRT reader should share readers w/ unchanged segments
> ---------------------------------------------------------------
>
> Key: LUCENE-2468
> URL: https://issues.apache.org/jira/browse/LUCENE-2468
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Yonik Seeley
> Assignee: Michael McCandless
> Attachments: CacheTest.java, DeletionAwareConstantScoreQuery.java,
> LUCENE-2468.patch, LUCENE-2468.patch
>
>
> A repoen on an NRT reader doesn't seem to share readers for those segments
> that are unchanged.
> http://search.lucidimagination.com/search/document/9f0335d480d2e637/nrt_and_caching_based_on_indexreader
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
