one thing to note ... we were using the /admin/xml/queues.jsp page to get
stats from ActiveMQ into splunk for monitoring and alerting. We've worked
around the issue by using the jolokia endpoint, e.g.:
/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=*,destinationName=*,destinationType
I'm also using Java 1.8 ... with both 5.13.3 and 5.14.5
Also, to Tim's earlier request, I deleted all the queues (using the
/admin/queues.jsp page) and still got the same error when I went to the
/admin/xml/queues/jsp page.
I'll filed a JIRA: https://issues.apache.org/jira/browse/AMQ-6685
--
V
We just upgraded from 5.13.3 to 5.14.5 and now when we try to get queue stats
form /admin/xml/queues.jsp we get a page with the following errors:
/This page contains the following errors:
error on line 4 at column 666: Namespace prefix c on forEach is not defined
error on line 5 at column 14: Une
We ran a couple tests with conduitSubscriptions="true" and
decreaseNetworkConsumerPriority="true".
The first test we had 3 brokers, 2 producers, and 4 consumers hosts ... and
made sure that each broker had at least 1 consumer host connected ... and
everything kept up just fine.
We ran again with
ok, we re-ran the test with 3 brokers, 2 producer hosts, and 4 consumer hosts
(each consumer host has 50 consumers on a single connection) and this time
with the proper configs on the consumer side and the system behaved a little
better, but still started queueing on the broker at about 500 tps. Si
oops, sorry about the last post ... the test with the 3 brokers, 2 producers,
and 4 consumers had a bad configuration on the consumer side (something
outside the scope of ActiveMQ) ... we're running that same test again (with
conduitSubscriptions="false" and decreasNetworkConsumerPriority="false")
Tim,
We just ran another test with all 3 brokers, 2 producer hosts, and 4
consumer hosts ... and made sure that every broker had at least one consumer
host directly connected ... and we saw the queues on broker1 build up
immediately - event during the "ramp up" portion of the test. We're going to
I'm having a similar issue with 5.13.3. We have 3 brokers configured as a
grid network (each connected to the other 2). For the clients, we are using
JmsTemplate to produce messages from 2 hosts ... and
DefaultMessageListenerContainer to consume from another 2 hosts. Each
consumer client is a singl
@rajdavies,
After reading https://issues.apache.org/jira/browse/AMQ-6252 and the Java
docs for HealthView and HealthViewMBean, as well as the latest source code
for HealthView.java (since 5.13.3) ... it looks like one would first need to
call HealthView.healthList() ... otherwise, the HealthViewMB
ok, I've done a little further reading here:
https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html
and realized that the ZooKeeper server will negotiate the actual timeout
with the client, so even if zkSessionTimeout on the ActiveMQ side is set to
2s ... if the "tick time" on the ZooKee
I'm using activemq 5.13.3 with replicatedLevelDB and I'm wondering how to
best configure the zkSessionTimeout setting as it relates to ZooKeeper's
"tick time".
http://activemq.apache.org/replicated-leveldb-store.html shows that
zkSessionTimeout defaults to 2s.
https://zookeeper.apache.org/doc/r3.
Tim,
Thanks for the quick response.
Regarding setting up and starting a full ActiveMQConnection:
1) No problem on the links, I appreciate the details. I was hoping to have
something a little more lightweight than actually creating a connection and
then closing it ... seems lie creating a new conn
I have an HA cluster (currently version 5.13.3) using replicated leveldb and
I want to put the cluster behind an F5 so that clients only need to know the
VIP on the F5, and the F5 forwards the client to the current live "master".
This way, if I change my broker topology (e.g. add another HA cluster
13 matches
Mail list logo
