[
https://issues.apache.org/jira/browse/SOLR-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013144#comment-17013144
]
ASF subversion and git services commented on SOLR-14134:
--------------------------------------------------------
Commit 66ec4228908dcabf60d3e6069967e576325829c6 in lucene-solr's branch
refs/heads/jira/SOLR-13101 from Andy Vuong
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=66ec422 ]
SOLR-14134: Add lazy and time-based evictiction of shared core concurrency
metada… (#1131)
* Add lazy and time-based evictiction of shared core concurrency metadata from
in-memory cache
* Switch back to simple map hash, evict on close, and evict on register
* Evict from unload
* Address comments
> Clear shared core's concurrency cache
> -------------------------------------
>
> Key: SOLR-14134
> URL: https://issues.apache.org/jira/browse/SOLR-14134
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Andy Vuong
> Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In shared collections, each replica's core has an associated entry in a
> metadata cache we call the shared core's concurrency cache (see
> SharedCoreConcurrencyController) that is used to facilitate concurrent
> indexing support of a single shard and associated optimizations.
> Entries are currently created on demand - i.e. when request triggered
> pulls/pushes are initiated but there's no way of clearing the cache unless
> the node goes down and JVM restarts.
> Eviction from this cache is needed to facilitate things such as collection
> name reuse. Currently if you delete a collection and then recreate, you can
> create a Replica containing the same core name as a previously active
> collection/replica and have a pre-existing entry in the concurrency cache
> (barring restarts between this point). The net effect is at least one
> indexing batch failure before the cache returns to a correct state.
> Eviction will also support scale - say 50k collections and thousands of
> entries for cores located in memory is highly ineffective especially if a
> large number of collections are accessed infrequently.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]