We have discussed this issue with Brave guys, pointing out to this specific use case (async call). Yes, all tracer are relying heavily on thread locals, however the detach / attach techniques are used to carry over the parent spans between threads.
On Thu, Dec 8, 2016 at 12:36 PM, Romain Manni-Bucau <[email protected]> wrote: > 2016-12-08 19:35 GMT+01:00 Andrey Redko <[email protected]>: > > > That's right, Sergey, we have done some work around span manipulation in > > case of async calls. The brave-cxf supports that as well but in any case > > things may get a bit more complicated. I agree with you. > > > > > Quick correction: bave DOESN'T since it relies on threadlocal which doesnt > passthrough the value or inherited thread local which leaks in this case. > > > > On Thu, Dec 8, 2016 at 10:32 AM, Sergey Beryozkin <[email protected]> > > wrote: > > > > > Hi Romain > > > > > > At least for CXF hTrace I know Andriy did some context switching to > keep > > > the track of the spans/etc. The span is detached, etc, I wonder how > does > > it > > > work under the hood > > > > > > Sergey > > > > > > On 08/12/16 14:34, Romain Manni-Bucau wrote: > > > > > >> 2016-12-08 15:14 GMT+01:00 Sergey Beryozkin <[email protected]>: > > >> > > >> Hi Romain > > >>> > > >>> Light-weight tracing (capturing few headers. etc) can be done with > > basic > > >>> custom features/interceptors, do you reckon there's a scope for > > shipping > > >>> something in CXF ? > > >>> > > >>> Yes > > >>> > > >> > > >> > > >> I suppose adding few basic interceptors to rt/management can work > > >>> > > >>> > > >> Yes, > > >> > > >> only trick is to support @Suspended case, see > > >> https://gist.github.com/rmannibucau/8c48d4182388b228046586fd6785a2f2 > > >> > > >> > > >> > > >>> Cheers, Sergey > > >>> > > >>> On 08/12/16 13:29, Romain Manni-Bucau wrote: > > >>> > > >>> 2016-12-08 14:24 GMT+01:00 Andrey Redko <[email protected]>: > > >>>> > > >>>> Right, it looks like really light version of tracing, which > > essentially > > >>>> > > >>>>> allows to figure out which service/host is the problem. I am not > sure > > >>>>> how > > >>>>> useful it could be in practice, and there is a large overlap with > > >>>>> logging > > >>>>> in this case. > > >>>>> > > >>>>> > > >>>>> - light: sure > > >>>>> > > >>>> - overlap with logging: no. Of course it ends up in a log (or > > aggregator > > >>>> or > > >>>> even other kind of storage) but the point is not "where to put it" > but > > >>>> "where to take the data from". Whatever logging system you use you > > will > > >>>> never get the full tracing if you dont handle it and the point of > the > > >>>> code > > >>>> is just to maintain the value and make it available for logging or > > other > > >>>> (a request header works well there) > > >>>> - how useful: if you have zipkin it is useless, if you have anything > > >>>> else > > >>>> (including an aggregator) it saves time and allows some > auto-analysis > > to > > >>>> be > > >>>> in place saving time for not that rare but easy errors > > >>>> > > >>>> Personally I see it as a kind of level 0 of analysis but > surprisingly > > if > > >>>> you compare the light vs powerful solutions, the light solves a lot > of > > >>>> cases in a simpler manner (Pareto?). > > >>>> > > >>>> > > >>>> On Thu, Dec 8, 2016 at 2:13 AM, Romain Manni-Bucau < > > >>>> [email protected] > > >>>> > > >>>>> > > >>>>>> wrote: > > >>>>> > > >>>>> 2016-12-08 9:10 GMT+01:00 Christian Schneider < > > [email protected] > > >>>>> >: > > >>>>> > > >>>>>> > > >>>>>> 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 http://cxf.apache.org/docs/message-logging.html > > >>>>>>> > > >>>>>>> > > >>>>>>> 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 > > >>>>>>> http://www.liquid-reality.de > > >>>>>>> > > >>>>>>> Open Source Architect > > >>>>>>> http://www.talend.com > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> -- > > >>> Sergey Beryozkin > > >>> > > >>> Talend Community Coders > > >>> http://coders.talend.com/ > > >>> > > >>> > > >> > > > > > >
