WIP TraceZ Processor#5
Conversation
| * Shut down the processor and do any cleanup required. Ended spans are | ||
| * exported before shutdown. After the call to Shutdown, subsequent calls to | ||
| * OnStart, OnEnd, ForceFlush or Shutdown will return immediately without | ||
| * doing anything. |
There was a problem hiding this comment.
Should there be a flag to signal if Shutdown is called so it can exit early in those functions?
Would it be better to throw an exception if any of those are called after Shutdown is called?
There was a problem hiding this comment.
Yeah I can add that, thanks!! I also made the functions return immediately instead, based on the doc comments
| completed_spans_.push_back(std::move(span)); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
One option is to collapse these two functions into one, and return some struct that bundles copies of the running and completed spans together.
struct RunningAndCompletedSpans {
<> running_spans_;
<> completed_spans_;
};
RunningAndCompletedSpans GetRunningAndCompletedSpansSnapshot() noexcept {
auto completed_spans = std::move(completed_spans_);
completed_spans.clear();
return {std::unordered_set<Recordable*>(running_spans_), completed_spans};
}
Something like that, that way it'll just give the Aggregator a consistent view while it's aggregating the spans.
There was a problem hiding this comment.
Okay, that sounds good! I should replace the running and completed getters in favor of returning them all, since the main goal is giving this information in a consistent manner and the aggregator should change its methods accordingly?
|
|
||
| private: | ||
| std::unique_ptr<opentelemetry::sdk::trace::SpanExporter> exporter_; | ||
| std::unordered_set<opentelemetry::sdk::trace::Recordable*> running_spans_; |
There was a problem hiding this comment.
Is the TraceZProcessor supposed to be a thread-safe class (do multiple threads share a single TraceZProcessor, or do they all have their own)?
There was a problem hiding this comment.
I think it's supposed to be thread-safe and hypothetical threads could share a single processor if I'm looking the spec correctly https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#interface-definition
I believe usually reading and writing spans in storage would be in the exporter, so adding thread safety isn't a mentioned for the processor and we would need it?
liadavid
left a comment
There was a problem hiding this comment.
Looks good, Nice tests! Some small comments.
|
|
||
| /** | ||
| * Initialize a span processor. | ||
| * @param exporter the exporter used by the span processor. Here, the purpose |
There was a problem hiding this comment.
Nit: Remove 'exporter' comment
| explicit TracezSpanProcessor() noexcept {} | ||
|
|
||
| /** | ||
| * Create a span recordable using the associated exporter. |
|
|
||
|
|
||
| /* | ||
| * Helper function to create a processor when the type of exporter doesn't |
|
|
||
|
|
||
| /* | ||
| * Helper function uses the current processor tov update spans contained in completed_spans |
| completed.clear(); | ||
| completed = std::move(spans.completed); | ||
| } | ||
| else { |
There was a problem hiding this comment.
Nit: It should be:
if () {
...
} else {
...
}
See: https://google.github.io/styleguide/cppguide.html#Conditionals
| TEST(TracezSpanProcessor, NoSpans) { | ||
| auto processor = MakeProcessor(); | ||
| auto spans = processor->GetSpanSnapshot(); | ||
| auto recordable = processor->MakeRecordable(); |
There was a problem hiding this comment.
'recordable' is not used here.
| namespace zpages | ||
| { | ||
| /** | ||
| * The span processor passes finished recordables to an exporter and is |
| * @return snapshot of all currently running spans and newly completed spans | ||
| * at the time that the function is called | ||
| */ | ||
| CollectedSpans GetSpanSnapshot() noexcept; |
There was a problem hiding this comment.
Worth adding a TODO: Verify/handle a case when GetSnapshot is called when spans start/end to run.
This should be covered by copy on write. While we plan to add it, it is good to "declare" that it is our plan.
…into zpages-tracez-processor1
This reverts commit eb81ff6.
…t/opentelemetry-cpp into zpages-tracez-processor1
…/kmanghat/opentelemetry-cpp into zpages-tracez-processor1" This reverts commit 38cc77a, reversing changes made to 2d061af.
|
See WIP PR for the main repo: open-telemetry#164 |
Progress includes: