[ 
https://issues.apache.org/jira/browse/SOLR-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885559#comment-16885559
 ] 

Andrzej Bialecki  edited comment on SOLR-13558 at 7/15/19 7:55 PM:
-------------------------------------------------------------------

This patch implements the dynamic modification of limits of all Solr cache 
implementations, using an API similar to the one proposed in the parent issue.

Some notes:
 * FastLRUCache has been modified to support both size and maxRamMB limits 
simultaneously.
 * LRUCache eviction has been modified to allow evicting multiple entries when 
the size limit is changed.
 * LFUCache doesn't support {{maxRamMB}} limit, unlike all other cache 
implementations. This can be added relatively easily, but probably in a 
separate issue.
 * more unit tests are needed to verify the behavior of caches when other 
parameters are changed (acceptableSize, minLimit, cleanupThread, etc)


was (Author: ab):
This patch implements dynamic modification of limits of all Solr cache 
implementations, using an API similar to the one proposed in the parent issue.

> Allow dynamic resizing of SolrCache-s
> -------------------------------------
>
>                 Key: SOLR-13558
>                 URL: https://issues.apache.org/jira/browse/SOLR-13558
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Andrzej Bialecki 
>            Assignee: Andrzej Bialecki 
>            Priority: Major
>         Attachments: SOLR-13558.patch
>
>
> Currently SolrCache limits are configured statically and can't be 
> reconfigured without cache re-initialization (core reload), which is costly. 
> In some situations it would help to be able to dynamically re-size the cache 
> based on the resource contention (such as the total heap size used for 
> caching across all cores in a node).
> Each cache implementation already knows how to evict its entries when it runs 
> into configured limits - what is missing is to expose this mechanism using a 
> uniform API.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to