[ 
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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to