[
https://issues.apache.org/jira/browse/ARTEMIS-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312236#comment-17312236
]
Gary Tully edited comment on ARTEMIS-3214 at 3/31/21, 9:53 AM:
---------------------------------------------------------------
this looks like a bug, set 50k maxSizeBytes, send 100k 1k messages with 5s
expiry. Come back after 10s, address size should be 0.
it is important that the page-in is bound, but there is pageMaxCache to control
that.
also it would make sense to bound the amount of work that the expiry/scanner
does in one sweep for a given address, possibly limit to processing the current
pageMaxCache
was (Author: gtully):
this looks like a bug, set 50k maxSizeBytes, send 100k 1k messages with 5s
expiry. Come back after 10s, address size should be 0.
it is important that the page-in is bound, but there is pageMaxCache to control
that.
> apply automatic page-in when all messages in a queue have expired
> -----------------------------------------------------------------
>
> Key: ARTEMIS-3214
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3214
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Affects Versions: 2.17.0
> Reporter: Erwin Dondorp
> Priority: Major
>
> When there are many messages in a queue, the messages are (by default) paged.
> However, when all these messages expire (given that a TTL is set), and there
> are no consumers, only the in-memory messages are removed. This leaves all
> paged messages in their on-disk state, thus preventing further actual message
> expiry.
> Is it possible to add a function where messages are paged-in more often? e.g.
> when the in-memory part of the queue is empty during an expiry-sweep. This is
> useful even when only one chunk is paged-in to not keep the expiry-thread
> unreasonably busy. This will eventually lead to the actual expiry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
