Tracking issue for ClientCallTracer APIs being experimental

[voidzcy]

Introducing ClientCallTracer class, which extends ClientStreamTracer.Factory for tracing client side RPC events, with an addition of exposing tracer component properties via Attributes.

• Client side tracer implementers would provide same tracing logic as using ClientStreamTracer.Factory, with a plus of ClientCallTracer#getTracerAttributes(Attributes.Builder) to put properties being exposed externally.

• New API ClientCall#getTracerAttributes() bridges the access to tracer properties on ClientCall and on ClientCallTracer.

Why existing ClientStreamTracer.Factory is not enough?

• The problem came up with external users/frameworks wishing to access tracer specific properties (e.g., SpanId or TracerId created by Census when CensusTracingModule is applied). Putting tracer properties in CallOptions and propagating through ClientInterceptor#interceptCall(...) only makes tracer properties accessible in interceptor applying time, it does not tie tracer properties to the ClientCall instance. External frameworks/users are not able to access tracer properties unless installing a ClientInterceptor that runs strictly after the tracer installing interceptor. This raises two problems:

  • Relying on a certain order of interceptors is problematic, which makes special cases for particular interceptors. It is hard to maintain the ordering of different interceptors as there are many places registering interceptors (in-channel, wrapping channel, global interceptors).
  • Currently, interceptors for Census modules run last to avoid ClientStreamTracer.Factory being overwritten in CallOptions. So no other interceptors are able to access tracer specific properties.

[voidzcy]

Deprecated.

[ejona86]

This API was abandoned before being added. #6090 was closed before being merged.