We have extended properties in AMQP as we cannot modify the message on the server.
This opens back a discussion about external dependencies. Such as serializarion. Etc. right ? On Mon, Aug 20, 2018 at 10:27 AM michael.andre.pearce <michael.andre.pea...@me.com.invalid> wrote: > So for AMQP it would be to wrap around those clients, just the same as the > JMS one does. > Re openwire clients are jms so you just wrap that the same. > Re > serve side tracing, id be wary here as will add perf hit. But if > integration thats what the plugins api is for if you really want to add > that. > Id be wary of directly integrating on vendors tracing or metrics directly > into the activemq artemis broker. > as what happens say another person wanted new relic, appdynamics, > dynatrace? We simply should expose an api suitable for those wanting to > make plugin, and those integrations own their plugins, eg i wouldnt expect > us to host/maintain new relic or appdynamics plugin either. > > > > > Sent from my Samsung Galaxy smartphone. > -------- Original message --------From: "Lohmann Carsten (INST/ECS4)" < > carsten.lohm...@bosch-si.com> Date: 20/08/2018 14:43 (GMT+00:00) To: > users@activemq.apache.org Subject: AW: [DISCUSS] OpenTracing in Artemis > > We use similar tech in my org for transactional tracing and stiching, we > use a > > proprietary off the shelf software, its one of the big APMs > > If you build the tracing to wrap around the clients api's eg, in JMS the > JMS > > Message, and put the magical uuid thats used to stich in that. > > This would also make your solution agnostic of broker implementation of > JMS. > > This is how the vendor product we use achieves this successfully without > needing > > upstream product changes. > > But with that, there's no tracing information being collected about what > is done *inside* Artemis, only propagating the client's tracing context > across the Artemis step, right? > > And a non-JMS centric use case would be for example, having an OpenTracing > aware AMQP client that sends a message (with included tracing uuid in the > delivery annotations) to Artemis. > Currently this tracing uuid isn't propagated to the consumer. > > > > I notice that theres an opentracing-contrib github project already that > seems to > > collect and be a home for all opentracing integrations. So anything done > prob > > should sit there. > > On that note, i notice there is a jms wrapper already to stich the end > users > > application flow over jms. (opentracing-contrib/java-jms) > > The opentracing-contrib project would certainly be a possible place. > Question is, whether putting it inside the Artemis repo wouldn't be better > from an integration point of view, making OpenTracing support an Artemis > feature. > > > > -- Clebert Suconic
