Is your feature request related to a problem? Please describe.
The OTLP exporter specification says that transient errors MUST be handled with a retry strategy, where the retriable gRPC error codes are defined in the OTLP spec.
I don't believe this is currently embodied in the java code anywhere, but that it could be by specifying an appropriate service config when setting up the managed channel when building the Span / Metric OTLP exporters. (Here's an example of setting up a managed channel and here's the service config JSON that specifies the retry policy.
Describe the solution you'd like
I think we should implement gRPC retry for the Span and Metric OTLP exporters by specifying the service config.
Additional context
I couldn't find any historical context as to why this isn't implemented today, but it seems like it should be reasonably straight forward to do.
Is your feature request related to a problem? Please describe.
The OTLP exporter specification says that transient errors MUST be handled with a retry strategy, where the retriable gRPC error codes are defined in the OTLP spec.
I don't believe this is currently embodied in the java code anywhere, but that it could be by specifying an appropriate service config when setting up the managed channel when building the Span / Metric OTLP exporters. (Here's an example of setting up a managed channel and here's the service config JSON that specifies the retry policy.
Describe the solution you'd like
I think we should implement gRPC retry for the Span and Metric OTLP exporters by specifying the service config.
Additional context
I couldn't find any historical context as to why this isn't implemented today, but it seems like it should be reasonably straight forward to do.