Add forceFlush on TracerSdkProvider.

[Oberon00]

Since there is no method to get the SpanProcessor(s),
there is no way to actually use the forceFlush API otherwise.

[arminru]

It makes sense to add this since #1009 likely won't be implemented. Thanks!

[Oberon00]

Even if #1009 would be implemented, I think forceFlush should be exposed in all places where shutdown is exposed.

[bogdandrutu]

Do we need this on the SDK? Probably yes, but would like to understand the motivation you had.

[Oberon00]

See #1068 (comment)

[carlosalberto]

This is also in the Specification ;)

[Oberon00]

Ah, makes sense!

[Oberon00]

@carlosalberto Actually it's not, only shutdown is: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-tracing.md#shutdown-1. Also forceFlush is not on the exporter. I'll try creating a PR.

[Oberon00]

Reading more carefully, it seems that the spec does not even specify shutdown on the TracerProvider either, only the getTracer method in the API.

[jkwatson]

It's only in the spec for a SpanProcessor, not for the SDK Tracer implementation, unless I missed that somewhere.

[carlosalberto]

Oh, right. I misread that one. In any case, I think it makes sense to have in the Tracer SDK section. I don't imagine keeping the processor object around for this specific task.

[jkwatson]

@bogdandrutu any more clarification needed on this?

[bogdandrutu]

Even if #1009 would be implemented, I think forceFlush should be exposed in all places where shutdown is exposed.

I think this sentence applies only to push base SDKs like trace, in metrics we have a pull mechanism from the exporter to periodically get aggregated metrics so in that case no flush available even though we have shutdown.

[jkwatson]

Just for the sake of argument: If you have to create and assign the span processor(s) when you configure the SDK, why not just keep a reference to them if you need the force-flush functionality? Either you keep a reference to the processor(s), or to the TracerSDK itself, seems like you get the same functionality either way.

[Oberon00]

when you configure the SDK, why not just keep a reference to them

The component initializing the SDK is typically different from the component that knows when to flush. Also, I would need the reference just for that.

Either you keep a reference to the processor(s), or to the TracerSDK itself

I don't need to do that, as I can use the OpenTelemetrySdk singleton's getTracerProvider method.

[jkwatson]

Either you keep a reference to the processor(s), or to the TracerSDK itself

I don't need to do that, as I can use the OpenTelemetrySdk singleton's getTracerProvider method.

That's fair. Thanks for walking through the thought process with me. This seems fine; if we're going to have forceFlush, we might as well make it a first-class concept, on the SDK at least.

[Oberon00]

A more detailed use case description: For example, I might configure the disruptor batch span processor in my startup. Then I use some (hypothetical) AWS Lambda integration that flushes each time before the lambda is about to be suspended. That integration would then need to be passed a reference to the spanprocessor.

What is more, the TracerSdkSharedState uses an internal MultiSpanProcessor. It is absolutely impossible to flush that right now, so I would need to maintain and manually loop-flush a list of span processors.