We will not be using a network of brokers, due to the possibility of
persistent messages getting undelivered after a failover (not sure if
orphaned is a better term?) due to this issue:
https://issues.apache.org/jira/browse/AMQ-5897
We are using a shared filesystem master/slave setup. We are
hawtio is no longer bundled with activemq, but you can still use it just
fine. Hawtio continues to include an activemq plugin to help
manage/visualize activemq info. There are a number of ways to run hawtio,
detailed here:
http://hawt.io/getstarted/
One reasonable setup for a production
You raise some valid-sounding concerns: specifically the information that
there can be message loss for non-durable subscriptions even in the absence
of a connection failure or broker failure.
Our cached items remain cached for extended periods, so we'd in trouble if
we miss a cache message for
Is this new broker independent from the first broker? If so, then just use
activemq-admin create to create the new instance, then customize the
con/activemq.xml as desired (to choose unique ports et al)
Or are you hoping to build a network of brokers where broker1 and broker2
cooperate and
We use a JMS topic to coordinate distributed caches. We have a topic called
caching using non-persistent messages. The subscribers are (of course)
non-durable.
A message in the topic means clear your cache for the specified datatype
(and id). Multiple webapps subscribe to this topic (and also
I have reported this issue in jira:
https://issues.apache.org/jira/browse/AMQ-5900
I'm surprised at my struggle to identify a reliable HA solution for
activemq. Not sure if the issue is Solaris or issues in my config or
something else.
1. master/slave fail-over was a bust due to
-22 17:57:20,400 | INFO | Stopped
LevelDB[/home/jlindwall/servers/activemq-replicated-leveldb-cluster/node2/data/LevelDB]
| org.apache.activemq.leveldb.LevelDBStore | LevelDB IOException handler.
Anybody successfully using leveldb on solaris?
Thanks!
--
View this message in context:
http
Below I am going to attempt to include my java code (producer and consumer)
as well as the activemq.xml files for my masters and slaves.
The consumer is called ActiveMQFailOverDurableMessageListener.java, and I
run it using a discovery transport url, like this:
/usr/bin/java -cp .
Some followup info: I've been playing with various settings today to no
avail. I did find one interesting piece of information however: if I kill
the master using the stop command (graceful shutdown) instead of using
kill -9, the system behaves as I expect!
Below is the log output from my
I have a cluster consisting of 2 pairs of master/slaves: m1/s1 and m2/s2.
They use multicast://default for their networkConnectors. 1 subscriber, 1
publisher, also both using multicast urls. My subscriber is a durable
subscriber. Msgs are persistent.
I am testing system robustness in the face
Thanks for the response. We can live with at least once semantics, so we'll
go that route.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Client-reaction-to-server-failure-tp4698426p4699364.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
We are planning a cluster using master/slave pairs. The clients will use the
discovery protocol.
What happens when the server that a client is connected to goes down? In
the simple case, my understanding is that the activemq client library will
automatically reconnect to another server in the
I see that I can add a daemon=true parameter to tcp broker urls to force
the ActiveMQ Transport threads to be created as daemon threads. I've tested
this and it works fine, e.g.
failover:(tcp://172.202.23.11:61616?daemon=true,tcp://172.202.23.11:61617?daemon=true)?initialReconnectDelay=100
I solved my own problem. As is so often the case, it was a case of user
shooting self in foot
http://activemq.apache.org/networks-of-brokers.html
http://activemq.apache.org/networks-of-brokers.html
As mentioned in the documentation, you need to have *advisories enabled* for
a network of
Just to be explicit for people looking for the solution in future, the fix
was to remove /advisorySupport=false/ from the broker element in
activemq.xml.
Change:
To this:
--
View this message in context:
I'm trying to verify that my multicast cluster is working properly: clients
on any node should receive msgs sent to any other node.
Using 5.10, on Ubuntu
In the past I have successfully created a network of brokers using a static
list of urls. I could then run a subscriber client that connected
I have been happily testing clusters of activemq 5.10 nodes; we desire highly
available distributed topics. I just wanted to sanity check my
understanding of the persistent storage with a cluster.
My master cluster nodes are each configured with a unique kahaDB directory.
i.e.
The following documentation mentions a Master/Slave setup whereby messages
are replicated between two brokers. This sounds different then the Shared
Filesystem Master/Slave configuration in other docs, which lets a passive
slave wake-up and take over for a failed master.
Is this
One of our legacy applications creates over a hundred JMS connections to a
topic (non persistent messages) on a remote broker (one per servlet
basically). Each connection is receiving the same messages (ie same message
selector). We have over a hundred instances of this application running.
I
Shucks, I had grown fond of hawtio. Are there technical reasons for the
removal of hawtio? (e.g. it has bugs or problems that make it untrustworthy
or unstable, etc).
What are the reasons for the removal of hawtio?
Thanks,
John Lindwall
--
View this message in context:
In our system message consumers come and go over time, some long-lived and
some short. All msgs are non-persistent.
We need all clients to connect to the same broker; if that broker goes down
all clients must connect to the same secondary broker, and so on.
Is this the way to go?
I suspect this is an environmental problem, because it is hard to believe
that this problem would not be noticed by many others...
I have been accessing hawtio for months via chrome and it works great. I
tried to give my boss a demo today of hawtio and he opened IE -- he logged
in and then was
== Short version ==
If we use failover with updateClusterClients, do all clients failover to the
*same* secondary broker?
server:
networkConnectors
networkConnector uri=multicast://default /
/networkConnectors
...
transportConnector name=openwire
I just tried replacing the webapps/hawtio with version 1.3.0. It kinda works
but I get an exception at startup, and one of the brokers (1 of 3) gets an
unending stream of javascript errors onscreen. I'm gonna stick with the
baked-in version for now.
INFO | Loading Blueprint contexts
Thanks all for the comments - I will rerun my stress test on Monday and
report back. I do not think my url-based parameter were being used because
of pilot error: I was using a jndi.properties file (a practice I have now
abandoned) and the connection url was specified in that file, not in my
I'll be re-running my stress test and Monday and report my findings back to
this thread. Thanks! Your questions are thought provoking.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Stress-testing-OOME-tp4677959p4678010.html
Sent from the ActiveMQ - User mailing list
Assume that consumers receiving duplicate messages are NOT a problem. Can
the fanout protocol possibly be used for this scenario? Maybe combined with
failover? (Can you tell I have not thought this through?)
Producers use fanout to duplicate all messages to 2 brokers. Consumers use
fanout
I am looking to get automatic client connection retry for a single broker.
By that I mean if the client connection to the broker fails, the client will
retry that connection.
It seems like the failover: protocol can give me this right?
failover:(tcp://server:61616)
The normal use case for
I am stress testing activemq 5.9.0 by sending a flood of non-persistent
messages to a topic using jmeter.
My producers are 50 threads attempting to deliver 1000 msgs/sec; each of
size 1K. There is merely a 1 millisecond delay in between message sends.
There are 100 consumers on the topic. It
Thanks for the tip. Is this documentation still accurate?
http://activemq.apache.org/what-is-the-prefetch-limit-for.html
I tried setting the limit on the connection url but got the same behavior:
tcp://testapp01:61616?jms.prefetchPolicy.all=50
I also tried setting the limit on my
I would suggest using a database connection pool as your datasource, like
c3p0, instead of BasicDataSource.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Re-More-than-10-consumers-tp4677780p4677906.html
Sent from the ActiveMQ - User mailing list archive at
... or better yet, kahadb (assuming you do not require a relational backing
store). Leveldb is supposed to be fast and cool, but I had some issue using
it under Solaris and have not successfully tried it yet.
--
View this message in context:
I'm trying out leveldb persistence on Solaris (sparc). Is this a supported
platform?
I get a DEBUG msg/stacktrace at startup saying the system cannot find
leveldbjni library, but I assume that is ok since we are using the pure java
implementation.
I then run my test with 100 durable
I'll try that snapshot, thanks. Um ... my svn skills are rusty. ANy idea why
this svn co command below does not actually seem to do anything?
$ svn checkout
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/
svn: OPTIONS of
Do I have any visibility into the contents/metadata of the kahadb datastore?
The mbean attributes exposed by the persistent adapter are quite minimal
(the location of the on-disk store, and a Size value which I do not really
understand).
It'd be nice to see how many messages it has in storage
Thanks for the advice. I do not really want to blindly delete all messages at
startup, though; just the expired ones.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Runaway-producer-Proper-way-to-clean-up-a-topic-tp4677644p4677672.html
Sent from the ActiveMQ - User
I have not reproduced the issue that I regionally experienced sadly. If I
do, I will attempt to capture it in a unit test as you suggest.
Interesting pont about the short timeout; if we indeed need such a short
timeout then persistence is pointless indeed.
My requirements are atypical it seems:
I have activemq configured with a durable subscriber to a topic backed by
oracle. I left a publisher running at a rate of 100 msgs/sec; each msg is
1K. The msgs expire in 30 secs. The durable subscriber disconnected so, as
expected, messages queued up in the db. After about 25 minutes I got an
In a previous post I described a problem that occurred in a jdbc-backed 5.9.0
broker with a durable subscriber. The producers got way ahead of the
consumer (which disconnected though did not unsubscribe). I had to restart
activemq as it was hung.
The messages in the topic had a 30 sec
A data point: Just today I successfully deleted a durable subscriber using
the hawtio console in 5.9.0
--
View this message in context:
http://activemq.2283324.n4.nabble.com/deleting-durable-subscriber-exception-tp4677521p4677646.html
Sent from the ActiveMQ - User mailing list archive at
I have configured activemq 5.9.0 to use jdbc persistence (oracle). I know
that part is correct because 3 ACTIVEMQ tables magically get created in
Oracle, and I see log messages that make me feel like jdbc is in use. So far
so good.
I am curious to see some of the queued messages in my database.
Some additional info: I can capture the summary information in my
jmeter-based subscriber so we can see the JMS message headers. I am
appending this info here in case it helps diagnose my problem.
FYI There are never any records created in ACTIVEMQ_ACKS either, as far as I
can tell. I am using
Interesting. I must have a flawed understanding of durable subscribers. I
thought it signified a consumer that can disconnect/reconnect and any
messages that arrived in the time while the subscriber was disconnected will
still be delivered. Cool, but not what we thought we needed.
Intuitively
Yep, using a durable subscriber did the trick indeed! Thanks.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Where-s-the-records-in-my-jdbc-persistence-store-tp4677577p4677591.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Our system sends small messages (1k) frequently, as data changes in the
system, to serve as notifications to listeners. The users (serving as
both producer and consumer) of these notifications are either human users or
batch processes. The humans process records slowly with pause times while
The duplicate broker concept is an interesting one; for our application the
deduping is trivial. We would we have to implement the duplicate
sending/receiving in our code, correct? I see a fanout: transport in
activemq but that does not seem to be quite what we would want.
However why do you
I am currently using jmeter to do some testing of several JMS servers,
including activeMQ 5.9.0. I'd be happy to help but you need to be more
specific; specifically what kind of problem are you having?
In the JMS PUblisher/Subscriber Samplers provided by jmeter, you can either
use a
In our application we want to use non-persistent messages but benefit from
failover (ie master-slave configuration using kahadb).
I did some experiments today and contrary to my expectations it looks like
activemq 5.9.0 supports this scenario. Huzzah! I had a producer and
consumer connecting to
48 matches
Mail list logo
