10:02 a.m.
Hi
On yesterday's watercooler discussion the main topic was about how to package the
individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into Hawkular/Kettle
repo. Although I agree that the kettle is the right place to bring together the components
and glue, not sure whether the actual code for the glue should reside in that single
repo.
My preference would be for all component related code, including that component's
integration with the bus, to be located in that component repo - that way there is a clear
owner of the code, and any changes to the core APIs are locally dealt across all
integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts to build what
it requires.
In terms of how the 'core' artifacts from each component should be enhanced with
the glue - may be the simplest way would be as one person suggested - use an overlay to
build upon the 'core' war artifact to add the glue artifacts (which in general
will probably just be bus integration). So each component only needs to produce a single
'core' war, but also manages the integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains the individual
component boundaries but enhances them with whatever they need to communicate in the
kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that we didn't
need to use overlays, but I don't believe this is the case.
Regards
Gary
10:10 a.m.
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 13, 2015 10:02:31 AM
Subject: [Hawkular-dev] The components, glue and kettle
Hi
On yesterday's watercooler discussion the main topic was about how to package
the individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into
Hawkular/Kettle repo. Although I agree that the kettle is the right place to
bring together the components and glue, not sure whether the actual code for
the glue should reside in that single repo.
My preference would be for all component related code, including that
component's integration with the bus, to be located in that component repo -
that way there is a clear owner of the code, and any changes to the core
APIs are locally dealt across all integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts
to build what it requires.
+1
In terms of how the 'core' artifacts from each component
should be enhanced
with the glue - may be the simplest way would be as one person suggested -
use an overlay to build upon the 'core' war artifact to add the glue
artifacts (which in general will probably just be bus integration). So each
component only needs to produce a single 'core' war, but also manages the
integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains
the individual component boundaries but enhances them with whatever they
need to communicate in the kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that
we didn't need to use overlays, but I don't believe this is the case.
My only open question about packaging is about which one is better for integration
testing.
I like the idea to have in the component integration tests beyond simple junits, it can
help to test REST/Accounts/Bus integration as well as other minor regressions before to
put a component in hawkular (the artist known as kettle).
But the integration tests perhaps it can be discussed in future threads :-).
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:16 a.m.
+1 to integration tests (for bus and REST) being local within the component repo as well.
----- Original Message -----
----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Wednesday, May 13, 2015 10:02:31 AM
> Subject: [Hawkular-dev] The components, glue and kettle
>
> Hi
>
> On yesterday's watercooler discussion the main topic was about how to
> package
> the individual components, with the "glue" code, within kettle.
>
> There seems to be a general idea to move all bus integration code into
> Hawkular/Kettle repo. Although I agree that the kettle is the right place
> to
> bring together the components and glue, not sure whether the actual code
> for
> the glue should reside in that single repo.
>
> My preference would be for all component related code, including that
> component's integration with the bus, to be located in that component repo
> -
> that way there is a clear owner of the code, and any changes to the core
> APIs are locally dealt across all integration points that may be supported.
>
> Then the kettle repo can be responsible for selecting the relevant
> artifacts
> to build what it requires.
>
+1
> In terms of how the 'core' artifacts from each component should be enhanced
> with the glue - may be the simplest way would be as one person suggested -
> use an overlay to build upon the 'core' war artifact to add the glue
> artifacts (which in general will probably just be bus integration). So each
> component only needs to produce a single 'core' war, but also manages the
> integration artifacts locally.
>
> I think I would prefer this approach over a single ear, as it still retains
> the individual component boundaries but enhances them with whatever they
> need to communicate in the kettle.
>
> It would be even more ideal if jboss modules allowed exploded wars, so that
> we didn't need to use overlays, but I don't believe this is the case.
>
My only open question about packaging is about which one is better for
integration testing.
I like the idea to have in the component integration tests beyond simple
junits, it can help to test REST/Accounts/Bus integration as well as other
minor regressions before to put a component in hawkular (the artist known as
kettle).
But the integration tests perhaps it can be discussed in future threads :-).
> Regards
> Gary
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:20 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 05/13/2015 10:02 AM, Gary Brown wrote:
My preference would be for all component related code, including
that component's integration with the bus, to be located in that
component repo - that way there is a clear owner of the code, and
any changes to the core APIs are locally dealt across all
integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant
artifacts to build what it requires.
+1
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVUxdaAAoJECKM1e+fkPrXg5sH/A+e1z+SVtFmZ2F+T1afFu9s
HF+UIKdXc0GEY7QvjsBTlhEs7+62mahQLPe3VbKQ78MmcILTSK6bG2CHQaLdKR9i
I7Re11shGfXeRyUboAii8CnwQZ3phq6waCmfRMtW7cofCGxgJiOaGhTR8ZuQkJpa
qJtVhAD/dfXR7PR5/4jjHvI7Jkn4+M7gHuwLxRJHgomr+TKADWoWWlKTlysg21t2
PLX9zfP9PAmDqb/vvy6NFtv33yXmDV6Kg1mTNNLIiuQ3LUl+ACQTLA31YRIYt1dG
6xxq1Mvg27c7Xjfmi3wk/fATG3VUYtMFu0vWfcjlvfnGI+bt5Z1DbooodINVFw8=
=zoUE
-----END PGP SIGNATURE-----
11:53 a.m.
Hi,
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.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 13, 2015 11:02:31 AM
Subject: [Hawkular-dev] The components, glue and kettle
Hi
On yesterday's watercooler discussion the main topic was about how to package the
individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into Hawkular/Kettle
repo. Although I agree that the kettle is the right place to bring together the components
and glue, not sure whether the actual code for the glue should reside in that single
repo.
My preference would be for all component related code, including that component's
integration with the bus, to be located in that component repo - that way there is a clear
owner of the code, and any changes to the core APIs are locally dealt across all
integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts to build what
it requires.
In terms of how the 'core' artifacts from each component should be enhanced with
the glue - may be the simplest way would be as one person suggested - use an overlay to
build upon the 'core' war artifact to add the glue artifacts (which in general
will probably just be bus integration). So each component only needs to produce a single
'core' war, but also manages the integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains the individual
component boundaries but enhances them with whatever they need to communicate in the
kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that we didn't
need to use overlays, but I don't believe this is the case.
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:01 p.m.
Hi Micke
Its a valid point - but I don't believe the bus API is going to change that often, and
therefore I think the benefits of bus integration code in the component repos outweighs
the potential impact of such a change to the bus API.
Regards
Gary
----- Original Message -----
Hi,
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.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 13, 2015 11:02:31 AM
Subject: [Hawkular-dev] The components, glue and kettle
Hi
On yesterday's watercooler discussion the main topic was about how to package
the individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into
Hawkular/Kettle repo. Although I agree that the kettle is the right place to
bring together the components and glue, not sure whether the actual code for
the glue should reside in that single repo.
My preference would be for all component related code, including that
component's integration with the bus, to be located in that component repo -
that way there is a clear owner of the code, and any changes to the core
APIs are locally dealt across all integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts
to build what it requires.
In terms of how the 'core' artifacts from each component should be enhanced
with the glue - may be the simplest way would be as one person suggested -
use an overlay to build upon the 'core' war artifact to add the glue
artifacts (which in general will probably just be bus integration). So each
component only needs to produce a single 'core' war, but also manages the
integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains
the individual component boundaries but enhances them with whatever they
need to communicate in the kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that
we didn't need to use overlays, but I don't believe this is the case.
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:03 p.m.
-----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-----
12:25 p.m.
+1
On 05/13/2015 11:53 AM, Michael Burman wrote:
Hi,
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.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 13, 2015 11:02:31 AM
Subject: [Hawkular-dev] The components, glue and kettle
Hi
On yesterday's watercooler discussion the main topic was about how to package the
individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into Hawkular/Kettle
repo. Although I agree that the kettle is the right place to bring together the components
and glue, not sure whether the actual code for the glue should reside in that single
repo.
My preference would be for all component related code, including that component's
integration with the bus, to be located in that component repo - that way there is a clear
owner of the code, and any changes to the core APIs are locally dealt across all
integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts to build
what it requires.
In terms of how the 'core' artifacts from each component should be enhanced with
the glue - may be the simplest way would be as one person suggested - use an overlay to
build upon the 'core' war artifact to add the glue artifacts (which in general
will probably just be bus integration). So each component only needs to produce a single
'core' war, but also manages the integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains the
individual component boundaries but enhances them with whatever they need to communicate
in the kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that we didn't
need to use overlays, but I don't believe this is the case.
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:35 p.m.
To add to this.
I think we are trying to put too much into the components, defeating the
whole purpose of the componentization that I was advocating for in the
2014 f2f.
The components need to do minimum things and do them well. They should
go to maintenance relatively early, after that all the specifics need to
be in Hawkular.
One example, today we have calculation of 95 percentile within Metrics
[1], IMO this should be in hawkular (and Metrics need to provide a way
to add that functionality which I think was one thing discussed at f2f).
If I need 97 or 98 or 99 or 99.99 percentile, I should be able to do
that without another release of metrics.
Hawkular (the kettle) should be in charge of "deciding" who (which
components) receive what information based on Hawkular configuration.
[1] I understand that this was a shortcut. No finger pointing
Thomas
On 05/13/2015 12:25 PM, Thomas Heute wrote:
+1
On 05/13/2015 11:53 AM, Michael Burman wrote:
> Hi,
>
> 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.
>
> - Micke
>
> ----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Wednesday, May 13, 2015 11:02:31 AM
> Subject: [Hawkular-dev] The components, glue and kettle
>
> Hi
>
> On yesterday's watercooler discussion the main topic was about how to
> package the individual components, with the "glue" code, within kettle.
>
> There seems to be a general idea to move all bus integration code into
> Hawkular/Kettle repo. Although I agree that the kettle is the right
> place to bring together the components and glue, not sure whether the
> actual code for the glue should reside in that single repo.
>
> My preference would be for all component related code, including that
> component's integration with the bus, to be located in that component
> repo - that way there is a clear owner of the code, and any changes to
> the core APIs are locally dealt across all integration points that may
> be supported.
>
> Then the kettle repo can be responsible for selecting the relevant
> artifacts to build what it requires.
>
> In terms of how the 'core' artifacts from each component should be
> enhanced with the glue - may be the simplest way would be as one
> person suggested - use an overlay to build upon the 'core' war
> artifact to add the glue artifacts (which in general will probably
> just be bus integration). So each component only needs to produce a
> single 'core' war, but also manages the integration artifacts locally.
>
> I think I would prefer this approach over a single ear, as it still
> retains the individual component boundaries but enhances them with
> whatever they need to communicate in the kettle.
>
> It would be even more ideal if jboss modules allowed exploded wars, so
> that we didn't need to use overlays, but I don't believe this is the
> case.
>
> Regards
> Gary
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
12:49 p.m.
Hi Thomas
I agree that Hawkular/Kettle should have the ability to customise the components (e.g. add
further percentiles, alert definitions, etc), and how the components communicate. But I
still believe the code to support those customisations and communication options should
live within the component.
It makes the components more maintainable/testable - with Hawkular/Kettle being
responsible for assembly/customisation/end to end testing.
Regards
Gary
----- Original Message -----
To add to this.
I think we are trying to put too much into the components, defeating the
whole purpose of the componentization that I was advocating for in the
2014 f2f.
The components need to do minimum things and do them well. They should
go to maintenance relatively early, after that all the specifics need to
be in Hawkular.
One example, today we have calculation of 95 percentile within Metrics
[1], IMO this should be in hawkular (and Metrics need to provide a way
to add that functionality which I think was one thing discussed at f2f).
If I need 97 or 98 or 99 or 99.99 percentile, I should be able to do
that without another release of metrics.
Hawkular (the kettle) should be in charge of "deciding" who (which
components) receive what information based on Hawkular configuration.
[1] I understand that this was a shortcut. No finger pointing
Thomas
On 05/13/2015 12:25 PM, Thomas Heute wrote:
> +1
>
> On 05/13/2015 11:53 AM, Michael Burman wrote:
>> Hi,
>>
>> 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.
>>
>> - Micke
>>
>> ----- Original Message -----
>> From: "Gary Brown" <gbrown(a)redhat.com>
>> To: "Discussions around Hawkular development"
>> <hawkular-dev(a)lists.jboss.org>
>> Sent: Wednesday, May 13, 2015 11:02:31 AM
>> Subject: [Hawkular-dev] The components, glue and kettle
>>
>> Hi
>>
>> On yesterday's watercooler discussion the main topic was about how to
>> package the individual components, with the "glue" code, within
kettle.
>>
>> There seems to be a general idea to move all bus integration code into
>> Hawkular/Kettle repo. Although I agree that the kettle is the right
>> place to bring together the components and glue, not sure whether the
>> actual code for the glue should reside in that single repo.
>>
>> My preference would be for all component related code, including that
>> component's integration with the bus, to be located in that component
>> repo - that way there is a clear owner of the code, and any changes to
>> the core APIs are locally dealt across all integration points that may
>> be supported.
>>
>> Then the kettle repo can be responsible for selecting the relevant
>> artifacts to build what it requires.
>>
>> In terms of how the 'core' artifacts from each component should be
>> enhanced with the glue - may be the simplest way would be as one
>> person suggested - use an overlay to build upon the 'core' war
>> artifact to add the glue artifacts (which in general will probably
>> just be bus integration). So each component only needs to produce a
>> single 'core' war, but also manages the integration artifacts locally.
>>
>> I think I would prefer this approach over a single ear, as it still
>> retains the individual component boundaries but enhances them with
>> whatever they need to communicate in the kettle.
>>
>> It would be even more ideal if jboss modules allowed exploded wars, so
>> that we didn't need to use overlays, but I don't believe this is the
>> case.
>>
>> Regards
>> Gary
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:01 p.m.
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(a)redhat.com>
To: hawkular-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:09 a.m.
This is interesting. I am not too familiar with ActiveMQ, and I just took a look at
http://activemq.apache.org/masterslave.html
<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(a)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(a)redhat.com>
To: hawkular-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev 
3:27 p.m.
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(a)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(a)redhat.com >
To: hawkular-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:21 p.m.
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(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)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(a)redhat.com >
To: hawkular-dev(a)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.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
-----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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:44 p.m.
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(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)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(a)redhat.com >
> To: hawkular-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3274
days inactive
3275
days old
14 comments
8 participants
participants (8)
-
Gary Brown -
Jay Shaughnessy -
John Mazzitelli -
John Sanda -
Juraci Paixão Kröhling -
Lucas Ponce -
Michael Burman -
Thomas Heute