cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave
Date Thu, 08 Dec 2016 08:13:25 GMT
2016-12-08 9:10 GMT+01:00 Christian Schneider <>:

> The new logging support in rt/features/logging already creates exchange id
> and message id. It also allows to send the message id over the wire.
> I have already fed the data into elastic search. There I was able to
> correlate request to reply and request sent out from the client to request
> received on the server.
> Would that already work?
> See
It is closer to zipkin I think. The point of the previous solution is to
"pre-stack" (pre-compute) the data to have an immediate reading of it vs
requiring to rely on an aggregator to exploit it. It is generally added to
the access log and allows to associate immediately a request to its origin
(if you start getting a bunch of 500 or 401 and have a pipeline of > 3 hops
it makes the diagnostic very efficient compared to going to your aggregator
in general). Makes sense?

> Christian
> On 08.12.2016 08:58, Romain Manni-Bucau wrote:
>> Hello guys,
>> would it make sense to have a lighter tracker in cxf? idea is just to have
>> a header accumulator but not all the data zipkin requires. I often saw it
>> used in companies to track the data path but often it is self contained
>> and
>> only contains the host list. In term of delivery it would be a jaxrs
>> client/server provider (or interceptor) to handle the header and soap
>> equivalent probably. Wdyt?
>> (to make it clear client1 would send Cxf-Tracking: host1, if received on
>> host2 the program does another request it will send Cxf-Tracking:
>> host1,host2 etc...)
> --
> Christian Schneider
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message