[Hawkular-dev] The components, glue and kettle

[John Mazzitelli]

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 at 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 at redhat.com >
> To: hawkular-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>