2016-12-08 21:39 GMT+01:00 Andrey Redko <[email protected]>: > 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. > > Didn't see it in brave ATM but if handled that's good. Is it a dedicated ContextProvider as proposed - which allows to control it through standard @Context injection or something more specific?
> 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/8c48d4182388b228046586fd6785a2 > f2 > > > >> > > > >> > > > >> > > > >>> 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/ > > > >>> > > > >>> > > > >> > > > > > > > > > >
