[
https://issues.apache.org/jira/browse/ARTEMIS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298846#comment-17298846
]
ASF subversion and git services commented on ARTEMIS-3141:
----------------------------------------------------------
Commit 20007ad485bf8f7174db84e9c317b055b28d9756 in activemq-artemis's branch
refs/heads/master from gtully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=20007ad ]
ARTEMIS-3141 - respect the browse page limit on all queue controll/jmx
operations that use a queue browser
> limit the amount of data returned from jmx/queue control listMessages
> ---------------------------------------------------------------------
>
> Key: ARTEMIS-3141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3141
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JMX
> Affects Versions: 2.17.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The list methods of queue control that are exposed via jmx seem to be
> unbounded.
> 1) they list all messages
> 2) they display the full body
> To protect both the broker and the browser/UI/client it would make sense to
> limit both the number of messages and the size of the data that is returned.
> Imaging 500k messages pending messages with a body of 10k... and 400k are
> paged to disk. It would be crazy to try and list those.
> I imagine a:
> management-list-messages-max default 256
> management-list-messages-body-max default 256 or some such.
> I need to do some more tests to verify the extent a broker will do to support
> the current api. I note that the browse functionality can be paged and with
> out a page defaults to 200 messages. That is sensible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
