[
https://issues.apache.org/jira/browse/ARTEMIS-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404823#comment-17404823
]
Clebert Suconic commented on ARTEMIS-3444:
------------------------------------------
We should have an overall work on caching anyways... we should have a cache per
system and not per address.
I have seen more and more people with 1000s queues.. having the cache per
address is not feasible as it once was. I guess people are using artemis in
different ways this days so we definitely need to adapt and change here.
> Paging cache entries are not evicted although eligible for GC
> -------------------------------------------------------------
>
> Key: ARTEMIS-3444
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3444
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Minor
>
> Artemis Paging cache is using {{SoftValueLongObjectHashMap}} to collect page
> cache entries, that's using a
> [ReferenceQueue|https://docs.oracle.com/javase/8/docs/api/java/lang/ref/ReferenceQueue.html]
> to track values eligible for GC.
> Soft references become eligible to be collected by JVM according to
> {{-XX:SoftRefLRUPolicyMSPerMB}} configuration and it affects when broker can
> remove such entries from the mentioned {{SoftValueLongObjectHashMap}} too,
> after offering them in the mentioned
> [ReferenceQueue|https://docs.oracle.com/javase/8/docs/api/java/lang/ref/ReferenceQueue.html].
> The mechanism that allow broker to remove any pending memory is by processing
> the ref queue filled by the JVM, but it is triggered just if there's any
> interaction with the page cache (size/put/remove/get/iteration), meaning that
> if there are no interactions, the broker won't remove such entries and the
> related reference queue will grow larger and larger, further occupying memory
> (and likely GC resources).
> The paging cache should be able to remove such entries as soon as the JVM
> enqueue them on the map ref queue, instead and this could be achieved by
> allowing background processing of evicted soft refs.
>
> Given that
> [ReferenceQueue|https://docs.oracle.com/javase/8/docs/api/java/lang/ref/ReferenceQueue.html]
> expose timed thread-safe remove methods that could be called in background,
> we can considerusing a scheduled executor to monitor to remove evicted
> entries.
> It's key to manage concurrency of such remove operations while interacting
> with the map
> ie map put has created a soft ref that's immediately offered to the ref q and
> it's going to be removed *before* put complete, risking to "resurrect" it.
> An additional optimization could be to use a single shared reference queue,
> to allow using a single thread to perform the removal and (hence having the
> chance to issue parallel map removal requests for to the related
> {{PageCursorProviderImpl}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
