[experimental] observer pattern should not panic when Finish() called multiple times

[open-telemetry]

[experimental] observer pattern should not panic when Finish() called multiple times

[lizthegrey]

Also: with high concurrency it's possible to race and wind up with the parent span already being Finish()ed before the child span is created, causing the observer pattern to fail inside the start span observer.event creation

[jmacd]

Note: the experimental/streaming/sdk is meant to be experimental at this time. There is a TODO about not allowing out-of-order events which might help the second problem. The first problem should just be checked. However, the long term plan here would be to encode these events to some other destination, that will use far-more-real code to handle them.

[lizthegrey]

@jmacd any progress towards just getting the observer pattern into the regular rather than streaming SDK?

[freeformz]

FWIW: I feel that an observer pattern can support both streaming and non streaming exporters and should be the only internal implementation. With that said, I also haven't spent much time with the implementation in OT-Go yet.

[jmacd]

@lizthegrey @freeformz I am not actively pursuing this idea. While I support it 100%, it stands in the way of the OpenTelemetry timeline because it's not an API change. It's not a requirement, simply stated.

[lizthegrey]

Aha, https://github.com/open-telemetry/opentelemetry-go/blob/master/exporter/trace/stdout/stdout.go exists, and is sufficient to unblock me and I no longer need to see the observer pattern merged into the main SDK.

How waiting a few weeks changes things ;) this was not the case until Sep 28, and prior to Sep 28 you had to use the streaming SDK as opposed to the normal SDK to get stdout on spans.

[freeformz]

@jmacd totally get that.

[lizthegrey]

WTB access to tag issues so we can tag this low priority then. For now, tagging it in the title with [experimental]

[MrAlias]

This no longer looks relevant. Feel free to reopen if that is incorrect.