[ 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