[
https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670646#comment-16670646
]
ASF GitHub Bot commented on ARTEMIS-1710:
-----------------------------------------
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
The use case is covered in
https://issues.apache.org/jira/browse/ARTEMIS-1710
In a cloud-setting, we need to:
a) Have the broker derive (global) limits based on things like heap memory
in order to avoid falling over. This may be configured statically in the
broker.xml
b) Allow management messages to get through even if other addresses are
blocked by global-max-size (using BLOCK/FAIL policy, we do not wish to use
PAGE) so that our system can keep operating even if queues are full (i.e. we
can fetch queue stats and report back to user always)
Also, keep in mind that:
a) We don't know what addresses will exist beforehand and they are created
via management address.
b) We want to avoid setting limits per address via management, as that gets
super slow (I know this was confirmed by someone a while back, i don't know the
jira number). Perhaps the address-space limits proposed by @mtaylor would work
around that allowing us to set it statically for all addresses and make
management an exception in our configuration. I'm not sure how that would work
with not knowing the limits beforehand, or if it would be possible to 'disable'
the limit for management addresses by setting it to some special value.
> 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)
