[
https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669934#comment-16669934
]
ASF GitHub Bot commented on ARTEMIS-1710:
-----------------------------------------
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
@michaelandrepearce I've started working on the alternative one based on a
second level global limit, but TBH I've already found quite complex to add such
condition without breaking any of the current behaviours.
I'm evaluating if it is really the case to add a more precise feature whose
real use case would be the same of this one while involving a similar level of
dangerousness.
To obtain something similar to:
```xml
<global-max-size>Any value or left it -1 to be auto-tuned</global-max-size>
<management-address-ignore-global-max-size>true</management-address-ignore-global-max-size>
```
the alternative solution will need to configure:
```xml
<global-non-management-max-size>The original value used for
global-max-size</global-non-management-max-size>
<global-max-size>A value that is assumed to be unlimited</global-max-size>
```
Only this configuration can give the 100% guarantee to the user that any
management message won't be paged/fail/block regardless the current size of the
non-management addresses.
This type of configuration is dangerous for the same reasons this same PR
is.
In addition it will need to add:
- a new value that identify an unlimited value, because -1 for
`global-max-size` will force it to be auto-tuned
- a way to auto-tune the `global-non-management-max-size` too (as we're
doing it for `global-max-size`)
- an impact on any code paths of the check that we perform now
> 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)
