[jira] [Commented] (ARTEMIS-1710) Allow for management messages to pass the global-max-size limit

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671175#comment-16671175 ] 

ASF GitHub Bot commented on ARTEMIS-1710:
-----------------------------------------

Github user michaelandrepearce commented on the issue:

    https://github.com/apache/activemq-artemis/pull/2401
  
    @lulf if i understand @mtaylor proposal it would be that you could set address setting match to # meaning anything and set aggegate-size to the max size you want for all normal addresses. And then youd have a specific address setting that matches the management addresses that would have a seperate aggregate size. Thus meaning the space for management is seperated so its space wouldnt be consumed by the others


> 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)