2016-12-08 21:39 GMT+01:00 Andrey Redko :
> 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.
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-Buc
2016-12-08 19:35 GMT+01:00 Andrey Redko :
> 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 rel
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.
On Thu, Dec 8, 2016 at 10:32 AM, Sergey Beryozkin
wrote:
> Hi Romain
>
> At least for CXF hTr
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 :
Hi Romain
Li
2016-12-08 15:14 GMT+01:00 Sergey Beryozkin :
> 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/managemen
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 ?
I suppose adding few basic interceptors to rt/management can work
Cheers, Sergey
On 08/12/16 13:29, Romain Manni-Buca
2016-12-08 14:24 GMT+01:00 Andrey Redko :
> 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: s
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.
On Thu, Dec 8, 2016 at 2:13 AM, Romain Manni-Bucau
wrote:
> 20
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 an
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
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
Absolutely, I would be happy to help you out. I will take another look on
brave-cxf to understand
which pieces should be kept in brave, which make sense to move to CXF.
Thanks!
Best Regards,
Andriy Redko
On Wed, Dec 7, 2016 at 12:29 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
>
Would be great if we could work together on this. I saw that you were part
of the brave-cxf development.
Maybe you could start with the actual tracing in cxf.
For me another important part is the brave OSGi integration and CXF-DOSGi
integration. So I could start with that.
I am not sure where to p
I think it is very good idea to integrate brave-cxf into CXF. Christian, do
you have enough time to work on that? I think I could help you out with
that, I have reviewed brave-cxf PRs awhile back. Thanks.
On Wed, Dec 7, 2016 at 5:00 AM, Christian Schneider wrote:
> I just talked to Adrian Cole.
I just talked to Adrian Cole. He prefers to have the brave cxf
integration in cxf instead of brave. So we can go ahead and improve the
module in cxf and he will deprecate the
brave-cxf module in brave once ours is good enough to cover all cases.
Christian
On 07.12.2016 11:46, Sergey Beryozkin
Hi Christian
May be you can contribute your CXF Brave Feature code to the Brave CXF 3
module (the docs show the interceptors are registered directly) ?
Otherwise Brave and CXF own Brave interceptors will start competing for
who has the latest code :-)
CXF HTrace is quite advanced thanks to t
Damn ... I just found there is also general CXF support for brave at
https://github.com/openzipkin/brave/tree/master/brave-cxf3 . So maybe this
already solved the problem before.
We should decide how to proceed.
I think one approach is to help at brave-cxf3 to make it as good as
possible and rever
That's right, the JAX-RS part should be supported by Brave already thanks
to dedicated CXF integration (I was involved in late-stage discussions for
the PR in question but not in the implementation).
Best Regards,
Andriy Redko
On Tue, Dec 6, 2016 at 12:09 PM, Christian Schneider <
ch...@die-s
My orignal plan was to just support SOAP as REST is well supported by brave
rest support already.
In the end my code was able to support both REST and SOAP without much
overhead so I removed the soap package again.
Christian
2016-12-06 14:41 GMT+01:00 Sergey Beryozkin :
> Christian, what is SOAP
Christian, what is SOAP specific in this code ?
Looks like that can work with JAX-RS too ?
Usually we try to accommodate both frontends, example, Andriy Redko made
sure HTrace interceptors work for JAXWS, similarly for Bean validation
Sergey
On 06/12/16 13:36, cschnei...@apache.org wrote:
21 matches
Mail list logo
