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/ > >>> > >>> > >> > > >
