-
Notifications
You must be signed in to change notification settings - Fork 821
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
fix(sdk-trace-base): eager exporting for batch span processor #3458
Closed
Closed
Changes from 13 commits
Commits
Show all changes
32 commits
Select commit
Hold shift + click to select a range
c339cd5
feat(sdk-trace-base): eager exporting for batch span processor
seemk 48fab8d
fix: use interval not timeout
seemk c12124b
chore: cleanup, add test for periodic exports
seemk 1b6fe87
Merge branch 'main' into bsp-eager-export
seemk e101c00
chore: update changelog
seemk d79ba67
fix: use setTimeout for browser compatibility
seemk faffbd2
refactor: spacing
seemk 307ca7c
Merge branch 'main' into bsp-eager-export
seemk 4e01111
fix: unref timeout timer
seemk 1879569
Merge branch 'main' into bsp-eager-export
seemk 746457e
Merge branch 'main' into bsp-eager-export
seemk b27af18
Merge branch 'main' into bsp-eager-export
seemk 525ad54
Merge branch 'main' into bsp-eager-export
seemk 487a3fb
Merge branch 'main' into bsp-eager-export
seemk 72f2726
Merge branch 'main' into bsp-eager-export
seemk b3718d1
Merge branch 'main' into bsp-eager-export
seemk 492458d
Merge branch 'main' into bsp-eager-export
seemk c16e528
Merge branch 'main' into bsp-eager-export
seemk 946e33b
Merge branch 'main' into bsp-eager-export
seemk 5598d25
Merge branch 'main' into bsp-eager-export
seemk b044f6d
Merge branch 'main' into bsp-eager-export
seemk 72fa72a
Merge branch 'main' into bsp-eager-export
seemk 2799733
Merge branch 'main' into bsp-eager-export
dyladan a1bfd82
Merge branch 'main' into bsp-eager-export
seemk 73732f6
Merge branch 'main' into bsp-eager-export
seemk e6d728b
Merge branch 'main' into bsp-eager-export
seemk 94597e1
Merge branch 'main' into bsp-eager-export
dyladan d5a1020
Remove duplicate changelog entry
dyladan 3c01099
Merge branch 'main' into bsp-eager-export
seemk 0bea748
Merge branch 'main' into bsp-eager-export
seemk 8ff333e
Merge branch 'main' into bsp-eager-export
seemk 68247b3
Merge branch 'main' into bsp-eager-export
seemk File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I'm not a fan of this pattern of "detecting" whether we should start a timer or not -- I perfer more explicit start/reset descriptions.
It took me a while to understand that this it the "flag" you are effectively using to determine whether there is "more" data (or not) and then whether to "reset" the timer.
I also don't like that you can "reset" an already running timer, as it could be very easy for someone to come along later and cause an endless (until it got full) delay if something is getting batched at a regular interval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_nextExport
is only used to avoid needlessly resetting the timer, i.e. it means that an export is already queued next cycle. Think about appending thousands of spans consecutively in the same event loop cycle.What would your alternative be to resetting an already running timer? Starting an export in a new promise right away when the buffer reaches the threshold can't be done as it would cause both too many concurrent exports and would nullify the concept of max queue size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this._timer will (should) be undefined when no timer is already running 😄 (as long as you also set the value to undefined (or null) within the setTimeout() implementation as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which is basically what the previous implementation was doing with
if (this._timer !== undefined) return;
in the _maybeSet function (although I'd also prefer to see a check that nothing is currently batched as well -- to avoid creating the timer in the first place.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The timer is now always running, basically this new implementation sets the timeout to 0 once the batch size is exceeded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if there is nothing in the batch we should not have any timer running...
ie. The timer should only be running if there is something waiting to be sent, otherwise, if an application is sitting doing nothing (because the user walked away) by having a running timer this can cause the device (client) to never go to sleep and therefore use more resource (power / battery) when not necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the spec (https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#batching-processor) we could probably simplify this whole processor to just be a
setInterval
and a list of spans. During the most recent spec iteration it was made clear that there is no need to wait for the previous export to complete before starting another one. The word "returns" is used very explicitly in the spec and refers to thread safety, not to the actual async task of the export.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't not needing to wait for previous export to complete invalidate the
maxQueueSize
parameter in this case? E.g. when starting an export when the batch size has been reachedThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noooo! Intervals are worse than timeout management as intervals get left behind and cause the APP/CPU to always be busy (at regular intervals)