You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Kevin Burton <bu...@spinn3r.com> on 2014/07/18 22:39:20 UTC
Any plans to add paging to the admin UI … too may items.
We have lots of queues and lots of scheduled messages.
The current UI essentially breaks. Dumping thousands of messages of
thousands of queues in my browser isn't too helpful … and also crashes my
browser.
Are there any plans to fix this?
--
Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>
<http://spinn3r.com>
Re: Any plans to add paging to the admin UI … too may items.
Posted by Rural Hunter <ru...@gmail.com>.
Does maxBrowsePageSize actually affect web admin UI? I read the doc and
seems the default value is 400. I didn't change it but I definitely
don't see it works on web UI. When I browse a queue with like thousands
of messages, the admin UI takes very long time and loads all the
messages in one page.
于 2014/7/21 22:34, Gary Tully 写道:
> do you set maxBrowsePageSize to something reasonable?
>
> The browser is limited by the minimum of: broker destination memory
> limit or maxBrowsePageSize.
> The thought is that there is very limited value in browsing all the
> messages in a large queue.
> Because of ordering, if there is a problem with dequeue, the chances
> are that the problem is with the first
> few messages, or with messages that have already been dispatched to consumers.
> For persistent messages, providing a way to bypass the memory cursors
> and view/manipulate messages
> directly in the store is non trivial.
>
> For your case, if you just nee to limit the amount of date shown
> rather than page through it all, the maxBrowsePageSize
> policy entry should suffice.
>
>
Re: Any plans to add paging to the admin UI … too may items.
Posted by Gary Tully <ga...@gmail.com>.
do you set maxBrowsePageSize to something reasonable?
The browser is limited by the minimum of: broker destination memory
limit or maxBrowsePageSize.
The thought is that there is very limited value in browsing all the
messages in a large queue.
Because of ordering, if there is a problem with dequeue, the chances
are that the problem is with the first
few messages, or with messages that have already been dispatched to consumers.
For persistent messages, providing a way to bypass the memory cursors
and view/manipulate messages
directly in the store is non trivial.
For your case, if you just nee to limit the amount of date shown
rather than page through it all, the maxBrowsePageSize
policy entry should suffice.
On 18 July 2014 21:39, Kevin Burton <bu...@spinn3r.com> wrote:
> We have lots of queues and lots of scheduled messages.
>
> The current UI essentially breaks. Dumping thousands of messages of
> thousands of queues in my browser isn't too helpful … and also crashes my
> browser.
>
> Are there any plans to fix this?
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
> <http://spinn3r.com>
--
http://redhat.com
http://blog.garytully.com
Re: Any plans to add paging to the admin UI … too may items.
Posted by Rural Hunter <ru...@gmail.com>.
+1
于 2014/7/19 4:39, Kevin Burton 写道:
> We have lots of queues and lots of scheduled messages.
>
> The current UI essentially breaks. Dumping thousands of messages of
> thousands of queues in my browser isn't too helpful … and also crashes my
> browser.
>
> Are there any plans to fix this?
>