[
https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670298#comment-16670298
]
ASF GitHub Bot commented on ARTEMIS-1710:
-----------------------------------------
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
I don't really like the idea of the double threshold. I think the
global-max-size limit should be the catch all case.
What would work better here is an accumulative-max-size setting that
applies to an address space that limits the total amount of memory used by all
addresses that match that address setting. Right now the limits are on a per
address basis, but many addresses can match the same address space.
Doing it this way allows a lot more flexibility in the broker, users can
limit certain address spaces for other reasons that to enable management
messages to flow, like for example, reserving capacity for critical
applications and blocking others. e.g. telemetry.# vs command.#
> Allow for management messages to pass the global-max-size limit
> ---------------------------------------------------------------
>
> Key: ARTEMIS-1710
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1710
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Ulf Lilleengen
> Assignee: Francesco Nigro
> Priority: Major
>
> Use case: global-max-size is set to some limit to prevent the broker from
> falling over. The broker is configured with N queues which are all blocked by
> this limit.
> If this limit is reached, however, it is not possible to perform management
> operations on the broker, so you're stuck.
>
> It should be possible to have an address like 'activemq.management' bypass
> this limit so that a broker can be recovered when the global-max-size is
> reached.
>
> To work around the problem, an external component needs to ensure that all
> addresses created have a max-size-bytes set so that worst case, there is some
> room left for 'activemq.management' address. In this case the broker
> configuration needs to be known by the component creating addresses which is
> impractical and it feels like this problem would be easier to solve inside
> the broker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
