[
https://issues.apache.org/jira/browse/SOLR-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283461#comment-13283461
]
Shawn Heisey commented on SOLR-3486:
------------------------------------
It's going to take me a while to digest what you've just said, but my first
thought is that I can't change the implementation without destroying the O(1)
nature. The cache is implemented in two parts - a simple map (HashMap) for
fast lookup, and an array of sets (LinkedHashSet[]) for fast frequency
ordering. When the frequency for an entry needs to be changed, it is removed
from one set and added to another.
Although it's not implemented as an actual iterator method, I have code to
iterate over the array. I should probably create an iterator and backwards
iterator, just to eliminate some duplicate code. If I don't already have a
remove method, I should be able to add one.
> The memory size of Solr caches should be configurable
> -----------------------------------------------------
>
> Key: SOLR-3486
> URL: https://issues.apache.org/jira/browse/SOLR-3486
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Adrien Grand
> Priority: Minor
> Attachments: SOLR-3486.patch, SOLR-3486.patch
>
>
> It is currently possible to configure the sizes of Solr caches based on the
> number of entries of the cache. The problem is that the memory size of cached
> values may vary a lot over time (depending on IndexReader.maxDoc and the
> queries that are run) although the JVM heap size does not.
> Having a configurable max size in bytes would also help optimize cache
> utilization, making it possible to store more values provided that they have
> a small memory footprint.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]