Does that apply for a hostname of localhost like the OP was using?
And can you give more details about exactly what switched, and in what
version of the JVM? I'd have expected hostname resolution to be handled by
the OS and/or a service like DNS, and that therefore the behavior would be
the same
Thanks for following up on this to make sure that one got created.
On Sep 23, 2016 9:34 AM, "wcrowell" wrote:
> Thank you!!! I was going to create one if it had not been done already.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-MQ-Shared-File-Syste
The sounds like a hostname to IP resolution. Newer JDK's require a
lookup for the hostname to an IP for JMX. Many cloud and VM instances do
not set this by default.
For example, if you have your hostname vm-123456
1. Add entry to /etc/hosts
127.0.0.1 vm-123456
2. Restart the JVM
On 9/2
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 restar
Did a JIRA issue get created on this?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Active-MQ-Shared-File-System-Master-Slave-with-Elastic-File-System-tp4715818p4716847.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Thank you!!! I was going to create one if it had not been done already.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Active-MQ-Shared-File-System-Master-Slave-with-Elastic-File-System-tp4715818p4716853.html
Sent from the ActiveMQ - User mailing list archive at Nabble.
Done: https://issues.apache.org/jira/browse/AMQ-6441
If anyone wants to update the ticket, feel free.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Active-MQ-Shared-File-System-Master-Slave-with-Elastic-File-System-tp4715818p4716851.html
Sent from the ActiveMQ - User m
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
r
No not yet, but I will do so now.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Active-MQ-Shared-File-System-Master-Slave-with-Elastic-File-System-tp4715818p4716848.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
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 messag
Just to confirm: your three brokers are writing their LevelDB files to
independent, separate disk locations, giving you three separate sets of
LevelDB files. Right?
Is the original master's set of data files corrupted? Or is it just the
two slaves for whom this happened?
On Sep 23, 2016 5:44 AM
If I remember correctly, you also can skip all the authentication checks by
starting JConsole (or JVisualVM) on the same machine as your broker,
running as the same user as the broker, and then selecting it from the
Local Processes list. Sometimes that's an option, sometime it's not, but
it was in
We ran into many problems getting JMX to work properly in our test
environment. We are running two instances on each server in our test
environment. We found the following changes got it to work and kept
them using independent mbean servers.
In the bin/env file add the following (We have it
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 message
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: Apache Artemis 1.0.0, 1.1.0, 1.2.0, 1.3.0
A class implementing the Serializable interface is free to implement
the “readObject(java.io.ObjectInputStream
in)” method however it chooses. This readObject method is used du
https://issues.apache.org/jira/browse/AMQ-6440
Tim Bain wrote
> I was going to write a JIRA enhancement request for that when I had some
> free time, but if you have time to write it before I get to it, that would
> be fine. Please put the link here if you do.
>
> On Sep 22, 2016 9:00 AM, "lich
17 matches
Mail list logo