Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

span exporter concurrency: expand on Export() requirements #2452

Merged
merged 12 commits into from
Jun 23, 2022
Merged
27 changes: 16 additions & 11 deletions specification/trace/sdk.md
Original file line number Diff line number Diff line change
Expand Up @@ -614,16 +614,22 @@ Protocol exporters that will implement this
function are typically expected to serialize and transmit the data to the
destination.

Export() will never be called concurrently for the same exporter instance.
Export() can be called again only after the current call returns.
By default Export() will never be called concurrently for the same exporter
instance and can be called again only after the current call returns. This does
not mean Export() is required to block until the batch is successfully sent.
What Export() does before returning is language and exporter dependent. However,
the implementation MUST document the concurrency characteristics the SDK
requires of the exporter.

Export() MUST NOT block indefinitely, there MUST be a reasonable upper limit
after which the call must time out with an error result (`Failure`).

Any retry logic that is required by the exporter is the responsibility
of the exporter. The default SDK SHOULD NOT implement retry logic, as
the required logic is likely to depend heavily on the specific protocol
and backend the spans are being sent to.
Concurrent requests and retry logic is the responsibility of the exporter. The
default SDK's Span Processors SHOULD NOT implement retry logic, as the required
logic is likely to depend heavily on the specific protocol and backend the spans
are being sent to. For example, the [OpenTelemetry Protocol (OTLP)
specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md)
tsloughter marked this conversation as resolved.
Show resolved Hide resolved
defines logic for both sending concurrent requests and retrying requests.

**Parameters:**

Expand All @@ -635,11 +641,10 @@ e.g. for spans in Java it will be typically `Collection<SpanData>`.

ExportResult is one of:

* `Success` - The batch has been successfully exported.
For protocol exporters this typically means that the data is sent over
the wire and delivered to the destination server.
* `Failure` - exporting failed. The batch must be dropped. For example, this
can happen when the batch contains bad data and cannot be serialized.
* `Success` - The batch has been successfully passed to the Exporter.
reyang marked this conversation as resolved.
Show resolved Hide resolved
* `Failure` - The Exporter failed to accept the batch. The batch must be
dropped. For example, this can happen when the batch contains bad data and
cannot be serialized.

Note: this result may be returned via an async mechanism or a callback, if that
is idiomatic for the language implementation.
Expand Down