Some cleanups in otlp exporter #1350
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
krnowak
requested review from
Aneurysm9,
evantorrie,
jmacd,
lizthegrey,
MrAlias and
XSAM
as code owners
krnowak
force-pushed
the
otlp-exporter-1
branch
from
f172c72
to
f20f5df
Compare
Codecov Report
@@ Coverage Diff @@
## master #1350 +/- ##
======================================
Coverage 77.5% 77.5%
======================================
Files 125 125
Lines 6131 6127 -4
======================================
- Hits 4753 4751 -2
+ Misses 1127 1126 -1
+ Partials 251 250 -1
|
MrAlias
approved these changes
Nov 19, 2020
This is not a good option - the user isn't likely to know how many worker goroutines is optimal. This should be something that an exporter should figure out itself. The second problem with the option is that it is specific to the metric transformation from SDK export format into protobuf. When the exporter starts supporting other protocols (HTTP/JSON for example), this option may be of no use. So the option should rather belong to the protocol, not to the exporter. Currently both mean the same, but later they will be separated, and this option breaks the separation.
Signalling channels are idiomatically defined as chan struct{}, so
let's make it so, to avoid confusion about the meaning of the bool
type.
If several goroutines call Shutdown at the same time, then the following scenario is possible: goroutine A locks a mutex, reads a started member, unlocks the mutex and gets preempted goroutine B locks a mutex, reads a started member, unlocks the mutex and gets preempted goroutine A does not return early in the "if !started" conditional and continues to close the connection and execute the rest of the function (where it finally sets the started member to false), gets preempted goroutine B also does not return early, because it got a copy of started before goroutine A set it to false, so it tries to close the connection again.
krnowak
force-pushed
the
otlp-exporter-1
branch
from
f20f5df
to
e407bf9
Compare
|
Updated. |
Aneurysm9
approved these changes
Nov 19, 2020
XSAM
approved these changes
Nov 20, 2020
Merged
AzfaarQureshi
pushed a commit
to open-o11y/opentelemetry-go
that referenced
this pull request
Dec 3, 2020
* Drop WorkerCount option
This is not a good option - the user isn't likely to know how many
worker goroutines is optimal. This should be something that an
exporter should figure out itself. The second problem with the option
is that it is specific to the metric transformation from SDK export
format into protobuf. When the exporter starts supporting other
protocols (HTTP/JSON for example), this option may be of no use. So
the option should rather belong to the protocol, not to the
exporter. Currently both mean the same, but later they will be
separated, and this option breaks the separation.
* Make stop channel a typical signalling channel
Signalling channels are idiomatically defined as chan struct{}, so
let's make it so, to avoid confusion about the meaning of the bool
type.
* Close a race when grpc connection is closed multiple times
If several goroutines call Shutdown at the same time, then the
following scenario is possible:
goroutine A locks a mutex, reads a started member, unlocks the mutex
and gets preempted
goroutine B locks a mutex, reads a started member, unlocks the mutex
and gets preempted
goroutine A does not return early in the "if !started" conditional and
continues to close the connection and execute the rest of the function
(where it finally sets the started member to false), gets preempted
goroutine B also does not return early, because it got a copy of
started before goroutine A set it to false, so it tries to close the
connection again.
* Update changelog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a first batch of work I did on otlp exporter. It's a small one, since the next commit belongs to a different person and I'd like to retain the authorship of it by filing a separate PR for it.
The whole work is in my branch: https://github.com/krnowak/opentelemetry-go/tree/otlp-conn