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 pa
Hi,
Could anyone help?
_Sanjit
On Sun, Jul 20, 2014 at 8:26 PM, Sanjit Mohanty
wrote:
>
> Hi JB,
> I'm already using network of brokers with failover URI.
>
> Assuming, I've 2 nodes in my cluster with IPs - ip1 & ip2 respectively,
> then the broker URL used by me is
>
>failover
On 07/21/2014 11:58 AM, kidfruit wrote:
My activemq is 5.10, nms is 1.6
I create two topic consumers in two different pc for the same tune such as
"topic://foo.bar", then send a map message from one pc.
If B send , A and B can receive message. no problem.
If A send , A can receive message, B ca
My activemq is 5.10, nms is 1.6
I create two topic consumers in two different pc for the same tune such as
"topic://foo.bar", then send a map message from one pc.
If B send , A and B can receive message. no problem.
If A send , A can receive message, B can't receive. But I check web
management, I
I stumbled on fpm and then onto a project that uses fpm to create ActiveMQ
debs from tarballs:
https://github.com/rgevaert/activemq2deb
After a few fixes (a PR is pending) I've managed to publish 5.7.0 and
5.10.0 to bintray. If anyone would like to try, add this to your
sources.list:
deb http://
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 deque
If I look at activemq.apache.org in Chrome it's missing a lot of styling.
According to the Chrome logs it's an https web page trying to load
resources from http and that's not allowed.
Firefox has things fine.
Hopefully someone can issue a fix as it looks like yet another project not
being mainta
Found a workaround ...
Topics are replaced by queues + persistent messages
Durable subscribers are replaced by other queues + camel routing to feed
them.
Camel routes can be updated live using JMX/Jolokia call
A benefit from using Camel is also that I can suspend the routing process.
For refere
