The HornetQ usage in RHQ was the same.  Each broker owned its own messages.  So if one broker went down those messages were trapped until it came up.  In RHQ this wasn't too terrible because the messaging use was all internal.  We'd have to decide about how bad it would be to have this happen for bus messages.  I don't think there will be any "free lunch" for us in this area.

On 5/14/2015 1:21 PM, Michael Burman wrote:
Hi,

Yes, there's a mode to support routing messages from one broker to another (store and forward). There's however a major limitation to it:

"Note though that a store and forward network is not a solution for message HA; if a broker fails in a Store and Forward network, the messages owned by that broker remain inside the broker's persistent store until the broker comes back online. If you need HA of messages then you need to use Master/Slave described above."

http://activemq.apache.org/how-do-distributed-queues-work.html

  - Micke

----- Original Message -----
From: "John Mazzitelli" <mazz@redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev@lists.jboss.org>
Sent: Thursday, May 14, 2015 4:27:25 PM
Subject: Re: [Hawkular-dev] The components, glue and kettle

Its been a while since I looked at the different distributed models for ActiveMQ but I thought there was more configurations available than simply master/slave.

I thought you could cluster brokers such that messages sent to one broker, could be received to consumers connected to other brokers and vice versa, with message persistence providing fault tolerance.

IIRC, I do remember in my testing I ran two kettle instances and sending messages via curl to one server was able to distribute those messages to consumers on the other.

As I understand it, isn't master/slave more for failover (that is, if the master goes down, the slave takes over)?

Again, its been a while since I looked into it, but I have to believe as mature as ActiveMQ is, that there are configurations of it we can use for distributed messaging in a way we need. I'm specifically talking about the later versions (like 5.10 we are using currently).

----- Original Message -----
This is interesting. I am not too familiar with ActiveMQ, and I just took a
look at http://activemq.apache.org/masterslave.html that describes the
master/slave configurations. To this point I have taken for granted that we
have distributed messaging. But I have to ask, how are we planning on
setting up/configuring distributed messaging?

Storm does require ZooKeeper and Spark has a cluster manager component which
can be ZooKeeper.




On May 13, 2015, at 8:01 AM, Michael Burman < miburman@redhat.com > wrote:

Hi,

More like the bus is only a JMS topic with "distributed" not meaning probably
what you hoped for. Since it's based on the ActiveMQ5 it's in HA
configuration a single broker with master/slave (which with replicated
LevelDB storage would then have ZooKeeper and everything else that's
massively complex to manage). So nothing like the networks created by
Hazelcast (eg. Vert.x underlying messaging infrastructure) / Storm / Spark /
Cassandra / etc.

These restrictions create their own headache when it comes to scaling in
Kubernetes for example, but I don't think we need to solve this issue quite
yet. Creating components without locking them to a JMS is the key forward
however as that would allow changing the implementation if requirements
dictate such in the future.

- Micke

----- Original Message -----
From: "Juraci Paixão Kröhling" < jpkroehling@redhat.com >
To: hawkular-dev@lists.jboss.org
Sent: Wednesday, May 13, 2015 1:03:13 PM
Subject: Re: [Hawkular-dev] The components, glue and kettle

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/13/2015 11:53 AM, Michael Burman wrote:


I disagree with the fact where the actual bus-integration component
should reside. The components themselves should have the
capabilities of allowing another component to connect to their
internal "feeds" but the actual component -> bus connector should
be in the Kettle-repository. Why? The bus-connector is highly
dependent on the actual bus implementation. If we would change the
bus in any way in terms of implementation or API, it would require
changes to every Hawkular component (thus, they wouldn't be
decoupled by design) instead of only changing the implementation at
the bus-component.

I haven't worked with the bus yet, but isn't "the bus" just a synonym
for "a distributed JMS topic" ?

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
/LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
=+U0e
-----END PGP SIGNATURE-----
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev


_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev