Strangely, the situation is a bit complicated:
In a prior test I received messages that the broker could not start a thread
due to not having enough heap available. It would not even shutdown, because
it could not start the shutdown thread. Eventually the broker got killed,
which then was taken
Currently I'm able to start some load testing using Artemis; The load is
nowhere near what I expect to need, but that's currently not the issue.
Of course I test both Artemis performance and the producers / consumers. The
performance itself is not at stake though, there's plenty of room for
Normally it is hard to see if two messages that are sent separately from each
other are really the same. To implement this on the broker level might
actually be a bit hard (imo)
However, there are a few ways you can work around this:
1) from the producer end: make sure that the producers do not
good to see this one;
Jolokia is offered out of the box and should work. I did alter the
"localhost" to "0.0.0.0" to make it available remotely, but care should be
taken, as this opens up the server for others. Also, I noticed that the
Artemis documentation regarding Jolokia is not 100% accurate
Another thing:
If you need a master/slave configuration... You may want to check out Apache
Artemis, which does "store replication"
--
View this message in context:
http://activemq.2283324.n4.nabble.com/LevelDB-vs-KahaDB-for-master-slave-Zookeeper-setup-tp4720633p4720699.html
Sent from the
(Replicated)LevelDB has some issues, and is indeed deprecated.
KahaDB does not officially have a replicating version. There has been some
work on it, which was abandoned in favor of ReplicatedLevelDB... If and when
this will be revived is unknown.
Then to the statement:
I need to implement a
pretty much what I would do if there wasn't a script that did just that (a
script is in this case just a tool to make sure you don't forget a step and
do the right thing in the right order... and make sure all is done safely)
--
View this message in context:
Why would you want this?
What should happen to various types of encoding? Is everything UTF-8? Or
ISO-8859-15 ...? Is your database configured according to what _all_
messages will have as their codepage?
Apart from having a database being discouraged, changing this datatype is
far more
Since we're advancing in our tests and Apache Artemis seems to suit our needs
most, a couple of questions I have not yet been able to find in the Artemis
User Manual (which has been a great resource, so far; very well written
indeed.)
Running:
- We run Artemis in a master/slave configuration,
Quick reply: 1.5.0 source was easier to get atm (behind some proxies, so it's
hard to get to git), so followed the instructions: they're clear, correct
and worked like a charm.
--
View this message in context:
Thanks;
I'll try to get the new version and try to compile the libaio and see if
that fixes this issue.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Artemis-1-5-0-fails-to-discover-libAIO-on-Linux-falls-back-to-NIO-tp4720184p4720195.html
Sent from the ActiveMQ - User
I have a RHEL 6.7 server wich has LibAIO installed, using Java 1.8.0_102
Artemis 1.4.0 finds and uses it with no problem, as this log line shows:
17:18:30,060 INFO [org.apache.activemq.artemis.core.server] AMQ221012:
Using AIO Journal
When I create a broker with the same parameters on the same
Just a question about this line:
A singleton class that used to publish huge non-persistent messages to one
topic with one connection. However, I got the error as follows:
How many of these huge messages have you sent, when did it break and how big
were those messages?
This data might help to
Could it be a (or more) messages staying on a queue, causing the logs not to
be cleared?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-leaks-file-descriptors-tp4718793p4718954.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
In fact, this always happens when a connection stops... If you have a network
of brokers and you stop one, you'll see this exception in the other brokers.
If your client stops, same... Maybe this exception deserves to be handled
like "Connection has disconnected." but apart from that... it's a
thanks for providing a good idea of what to expect; yet I think it's good to
be aware of this.
I did notice upon searching that there has been done some work to get Kahadb
replicating; is that completely abandoned or is it still something that
might get implemented (in a somewhat near future) I
Created a JIRA https://issues.apache.org/jira/browse/AMQ-6453 about this
issue; please let me know if you need more information.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-ReplicatedLevelDB-corruption-tp4716831p4717515.html
Sent from the ActiveMQ - User
Recently we started looking at ActiveMQ as a replacement of the JMS layer of
our backend, and thus I have been doing some test setups, using ActiveMQ
5.14.0
The requirements I'm looking at are:
- reliability: highly available, no corruption
- able to handle peak loads of approx. 250 msgs per
Browsing jira I noticed the removal of this component. Didn't dive deeper,
but it's no longer there.
Probably the same things can be done, but in a different way.
What would you like to do? What would you need the activemq-admin command
for?
--
View this message in context:
Gave the system a weekend time to see if it could recover automatically...
alas that's not the case.
However, when I stopped all brokers, changed one of the brokers with
'replicas="1"' (rather than 3); started it (kind of single mode) and started
the other brokers one by one so they could catch
Concluded the test now; No good news though.
After sending the 100.000 messages (which got consumed by services that in
turn also produced new messages and so had a flow from one queue to another
and another etc... resulting in about 1.500.000 messages in the few hours
that this test ran) I
possibly of note is that I had the sync option on the default (quorum_mem).
I have moved the data directories for each broker as an ".org" (for
safekeeping) and will try and see if quorum_disk is the way to prevent this
situation from happening. It will take a little while though to get definite
Yes, the three brokers are on separate (virtual) machines that write to their
own disk.
It's hard to determine (at this point) whether the original master got
corrupted, as it (at least) got corrupted after starting said broker again
(or was already corrupted to begin with)
--
View this
Recently I installed Apache ActiveMQ in a few different ways. One of those is
using ReplicatedLevelDB for a master/slave/slave setup.
Yesterday I did a bit of loadtesting: sending 100.000 messages with 100
threads producing the messages (used jmeter for that) (so each thread
produced 1000
I guess that is what I will do indeed; In normal operations time I'll hardly
use jconsole itself; but will have some centralized tools or just simply use
jolokia; Thanks for the advise given!
--
View this message in context:
It was a human (mine) error; I modified it... apologies if I had you thinking
it was a typo in the default.
I had been fiddling around... and have been even more:
I now realized a few things; The bind error I had earlier, which caused me
to think the problem was the port, actually was not the
Tim,
Your comment got me thinking why port 1099 was getting used rather than
11099 (and 12099); so I checked my java process and it's parameters: (ps -ef
| grep java); I noticed the parameter telling the port was not in it.
There's a stupid typo in the "env" files:
For no obvious reason, actually...
At first I did not have these parameters, neither on broker1 nor on broker2;
however, upon starting broker1 first, I noticed this line:
JMX consoles can connect to
service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi |
I think your ZooKeeper elects a master, look at the slave log:
2016-03-08 02:08:05,307 | INFO | Promoted to master |
org.apache.activemq.leveldb.replicated.MasterElector | main-EventThread
However, something goes wrong, and I think it is the hostname in your
persistenceAdapter:
I should note the following few things:
- Java version is 1.7.0 (openJDK)
- ActiveMQ is version 5.14.0
--
View this message in context:
http://activemq.2283324.n4.nabble.com/What-is-the-proper-way-to-configure-multiple-brokers-on-the-same-machine-in-regard-to-jmx-tp4715589p4715590.html
Sent
For various purposes, I wish to define various brokers on the same machine.
For example: some queues require ordering of data, and thus use the
replicatedLevelDb as persistence adapter, others don't even need persistence
or ordering and can use only memory in order to provide faster throughput,
31 matches
Mail list logo
