Spec out the MeterProvider ForceFlush and Shutdown requirement #1913
Conversation
| This method provides a way for provider to do any cleanup required. | ||
|
|
||
| `Shutdown` MUST be called only once for each `MeterProvider` instance. After the | ||
| call to `Shutdown`, subsequent attempts to get a `Meter` are not allowed. SDKs |
There was a problem hiding this comment.
I'd suggest that subsequent calls just return failure status.
There was a problem hiding this comment.
I took the wording from https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#shutdown.
I think the tricky part is "return failure status", we try to give language clients flexibility by saying "provide some way" so they can decide if exception or return value or something else (e.g. a global error handler) makes more sense.
|
|
||
| ### ForceFlush | ||
|
|
||
| TODO | ||
| This method provides a way for provider to notify the registered | ||
| [MetricReader](#metricreader) and [MetricExporter](#metricexporter) instances, |
There was a problem hiding this comment.
If I understand correctly MetricExporter is not directly connected to the Provider, so just notify the Reader is enough correct? It is Reader's responsibility to notify Exporter
There was a problem hiding this comment.
For Pull Exporters we've agreed to give implementers flexibility so they could (although we haven't seen a strong reason to do so) implement the Pull Exporter bypassing the Reader. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#pull-metric-exporter
Implementors MAY choose the best idiomatic design for their language. For example, they could generalize the Push Metric Exporter interface design and use that for consistency, they could model the pull exporter as MetricReader, or they could design a completely different pull exporter interface.
The wording here ensures that all the Readers and Exporters will be covered. An implementation could achieve this by having the Provider notifying the Readers, and Readers notifying Exporters.
reyang
added
area:sdk
…telemetry#1913) * spec out the MeterProvider ForceFlush and Shutdown requirement * adjust wording * adjust wording * fix wording
…telemetry#1913) * spec out the MeterProvider ForceFlush and Shutdown requirement * adjust wording * adjust wording * fix wording
This was previously left as TODO since it has dependency on the exporter (#1864) and reader (#1888) interface.