[ https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686767#comment-16686767 ]
ASF subversion and git services commented on ARTEMIS-1710: ---------------------------------------------------------- Commit f79ab66d0ddd178167b2b0adf00d53ba1602756b in activemq-artemis's branch refs/heads/2.6.x from [~nigro....@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=f79ab66 ] ARTEMIS-1710 Allow for management msgs to exceed global-max-size limit Added docs to explain the behaviour of management addresses on paging (cherry picked from commit 075a4024dfab01469bfec6eacc3b55501b0e0080) > Allow for management messages to exceed 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)