[
https://issues.apache.org/jira/browse/SOLR-15964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496365#comment-17496365
]
ASF subversion and git services commented on SOLR-15964:
--------------------------------------------------------
Commit f8703bd566dafc9be42d2c3f58f5043af847c730 in solr's branch
refs/heads/branch_9x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f8703bd ]
SOLR-15964: Fix test; use latch instead of a sleep (#674)
> Transient cores should not be unloaded/evicted while it's being used
> --------------------------------------------------------------------
>
> Key: SOLR-15964
> URL: https://issues.apache.org/jira/browse/SOLR-15964
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: 9.1
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> When using "transient cores" (transient=true on the core and configure
> transientCacheSize in solr.xml), Solr will evict/unload a core that appears
> to be getting little use when there is pressure on this cache. However, this
> mechanism doesn't truly check that the core isn't being used when making this
> decision. It could happen that a core is undergoing a long running operation
> (huge indexing batch?) but otherwise nothing else, and assuming some cache
> pressure on many others cores during this time, Solr will then "evict" this
> core. Solr will then consider this core unloaded even though it exists in
> memory and is open for this long-running operation for some time. If by bad
> luck a request comes in to use this core, Solr will attempt to load a new
> SolrCore for it which will fail due to the write lock file. At this point,
> the core is unusable until the node is restarted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
