9:32 a.m.
(I'm in PTO-mode, so I don't have an intelligible response to this yet but...)
Just for the record, the only reason why I coded up the wildfly agent to both send over
the metrics REST API and put a metric message on the bus was because (and only because)
that's what the Pinger does today and since the Pinger is the thing that is
"working" today, I just wanted to copy what it does so the agent can
"work" too.
I by no means am advocating that we have feeds send both messages (I don't think
anyone is saying that's the long term solution) - this is just following Heiko's
mantra "just get something to work" :)
As to whether feeds can or should be able to send messages on the bus, I can be convinced
either way.
----- Original Message -----
Ok, with the Jinn out of the lamp, let's move the discussion
we've had
privately amongst the team-leads to the public forum :)
With the ability to send rest messages to the bus we need to solve 1
fundamental question:
*Who is supposed be sending what kind of messages?*
It is clear, that any interested party should be able to listen to any
message.
But I am concerned about the "source" of messages.
For example I think it is wrong to send the message about metric being
collected to the bus prior to it being stored. It could happen that the
system
reacts to something that we will have no record about later on.
But with more "involved" components that do more work than just store data
upon arrival, the consequences of being out of sync between what's stored and
what's being reacted upon are potentially worse.
As an example, consider this:
* someone sends a "resource inventoried" message to the bus - what should
inventory think about it? Did the author make sure to do everything exactly
like inventory would if it sent the message itself?
* someone sends an "alert fired" message to the bus - what should alerts do
about it?
* someone DDoSes the the bus
I may be old fashioned in this, but I prefer consistency over eventual
consistency where possible. I don't think it would be too much of a
performance problem to architect the message flow like this:
1) anyone can listen on the bus
2) only Hawkular components can send messages to the bus (or rather the
hawkular glue code built atop the standalone components)
3) 3rd parties (including feeds) can send data only to the component
endpoints
(which will upon processing generate appropriate messages on the bus)
I am no expert in either distributed architectures or in microservices, so
this view may be naive and I'd love to be proven wrong about it, but I think
the concerns I raise are real and we should have a solid answer to them
whatever architecture we choose.
Cheers,
Lukas
On Thursday, April 02, 2015 17:51:31 John Mazzitelli wrote:
> I created a very simple REST client that you can use to send any json
> string
> as a bus message.
>
> It requires no dependencies other than apache httpclient and jboss logging.
>
> See:
> https://github.com/hawkular/hawkular-bus/tree/master/hawkular-bus-rest-clie
> nt
>
> new
> org.hawkular.bus.restclient.RestClient(url).postTopicMessage(topicName,
> jsonPayload, headers);
>
> My agent uses it to send metrics to the hawkular bus's metric topic. I use
> REST rather than the bus-common API because (AFAIK) the thinking is this
> agent can be deployed in something like WildFly Core where JMS API isn't
> even available.
>
> So right now, this agent should be sending data just like the Pinger - its
> sending metrics directly to Metrics REST interface for storage and sending
> those same metrics to the message bus's metric topic so other things like
> alerts can process it. Unfortunately, the kettle UI can't show any of it
> since it is tightly related to the Pinger's metrics and nothing else. But I
> think its working :) _______________________________________________
> 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