You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Clebert Suconic (Jira)" <ji...@apache.org> on 2023/01/27 21:40:00 UTC
[jira] [Commented] (ARTEMIS-3178) Provide a way to limit the size of an address after paged
[ https://issues.apache.org/jira/browse/ARTEMIS-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681461#comment-17681461 ]
Clebert Suconic commented on ARTEMIS-3178:
------------------------------------------
I'm updating the text here.
I'm adding Gary's original description as a comment, for future reference:
Currently there are max-size-bytes and global-max-size-bytes that trigger the blocking policy based on memory constraints. They don't cover paged messages on an address.
If a user wants to resource constrain an address, whether the messages are paged or not is orthogonal to the limit.
Having max-size-bytes encompass both paged an in-memory messages for an address seems intuitive.
Having max-size-in-memory configure the limits for paging (the current behaviour) may make sense.
That could also make page-cache-max-size obsolete, use max-size-in-memory.
The behaviour, blocking/fail etc would still hold, with page being an option for max-size-in-memory.
Naming is hard at best and there is an argument for adding new config rather than changing the meaning of an existing value. However in this case, the current configuration item, max-size-bytes could easily be inferred to be a limit, independent of paging. Paging is really an implementation detail from the outside.
The requirement is to be able to limit the resources allocated to an address. If you have a "small" address, there is only so much you can backlog there before blocking.
comments welcome!
> Provide a way to limit the size of an address after paged
> ---------------------------------------------------------
>
> Key: ARTEMIS-3178
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3178
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration
> Affects Versions: 2.17.0
> Reporter: Gary Tully
> Priority: Major
>
> Currently there are max-size-bytes and global-max-size-bytes that trigger the blocking policy based on memory constraints. They don't cover paged messages on an address.
> If a user wants to resource constrain an address, whether the messages are paged or not is orthogonal to the limit.
> Having max-size-bytes encompass both paged an in-memory messages for an address seems intuitive.
> Having max-size-in-memory configure the limits for paging (the current behaviour) may make sense.
> That could also make page-cache-max-size obsolete, use max-size-in-memory.
> The behaviour, blocking/fail etc would still hold, with page being an option for max-size-in-memory.
> Naming is hard at best and there is an argument for adding new config rather than changing the meaning of an existing value. However in this case, the current configuration item, max-size-bytes could easily be inferred to be a limit, independent of paging. Paging is really an implementation detail from the outside.
>
> The requirement is to be able to limit the resources allocated to an address. If you have a "small" address, there is only so much you can backlog there before blocking.
> comments welcome!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)