[
https://issues.apache.org/jira/browse/ARTEMIS-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro updated ARTEMIS-3444:
-------------------------------------
Description:
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.
was:
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.
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.
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
