[Hawkular-dev] start of message bus REST client
John Mazzitelli
mazz at redhat.com
Fri Apr 3 10:32:59 EDT 2015
(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 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
>
More information about the hawkular-dev
mailing list