xuanyu66 commented on pull request #6910: URL: https://github.com/apache/skywalking/pull/6910#issuecomment-834138108
> > > > > > > > > Do you mean customizing transport? > > > > > > > > > > > > > > > > > > > > > > > > yes, some package maybe customize transport , we need some safeguard > > > > > > > > > > > > > > > > > > > > > This is a known issue. In this scenario, there are two things maybe we need to consider. > > > > > > > > > > > > > > 1. whether we can get the "peer" from transport > > > > > > > 2. can we cover all customized cases > > > > > > > > > > > > > > > > > > I think we just set UNKNOWN, if someone want to enhance some customized transport, they can contribute themselves, we should only support official transport. > > > > > > What's your opinion? > > > > > > > > > > > > > > > My question would be, if this is not an official transport implementation, why should SkyWalking take care of? User could remove the thrift plugin directly. > > > > > > > > > > > > we want to trace thrift rpc call, and it work properly. But other dependency with customized transport cause IllegalStateException. > > > > > > > > > It seems strange. Are you saying your thrift is using 2 kinds of transport implementations in one service? Why? > > > > > > We use official transport to call rpc, jaeger use its customized transport to report trace span. > > there are two different thrift client > > That is strange, why SkyWalking needs to work with Jaeger? What is the use case? Which I want to say is that other package may implement their own customized transport to send message at the same time we use official transport to call rpc between services. Should we take this situation into account. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
