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.
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
feat: add dependency processor using Apache Beam #6560
base: main
Are you sure you want to change the base?
feat: add dependency processor using Apache Beam #6560
Changes from all commits
60fb334
5ccf68d
05dc78f
3c7ef35
de25c36
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / binary-size-check
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / spm (v2, jaeger)
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / hotrod (docker, v2)
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / crossdock
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / docker-images
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / all-in-one (v2)
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-linux-arm64
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / hotrod (k8s, v2)
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-linux-ppc64le
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-linux-amd64
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-windows-amd64
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-linux-s390x
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-darwin-arm64
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / build-binaries-darwin-amd64
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / lint
Check failure on line 113 in cmd/jaeger/internal/components.go
GitHub Actions / lint
Check failure on line 11 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator.go
GitHub Actions / unit-tests
Check failure on line 12 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator.go
GitHub Actions / unit-tests
Check failure on line 13 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator.go
GitHub Actions / unit-tests
Check failure on line 14 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator.go
GitHub Actions / unit-tests
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.
what's the motivation for making this a bound queue?
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 motivation for making the inputChan a bounded queue (a buffered channel with a fixed size, e.g., 1000) is primarily to manage backpressure, control resource usage, and ensure system stability in high-throughput scenarios
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.
Yes,it also can be implemented as follow:
Current code:
The bounded queue (capacity 1000) has several issues:
Better approaches may be:
This would:
The current arbitrary bound of 1000 should either be removed or justified with proper configuration and backpressure mechanisms.
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.
When a channel is unbounded, it cannot be written to unless there there is a reader waiting to consume it, so it provides a natural back pressure as the caller goroutine will be blocked and hold the remote caller. And it does not allow the queue to grow and accumulate unprocessed data while making it look like the processing was immediately successful.
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.
Ok,i will fix it . Could the part of code is ready to be merged ?
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.
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.
What is the motivation for having this done in the background instead of in the caller goroutine? Are the operations on Beam pipeline threadsafe or is this the reason for separation?
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 motivation for processing spans in the background (via a separate goroutine) rather than in the caller goroutine is primarily related to performance optimization, decoupling of concerns, and ensuring thread safety when interacting with the Apache Beam pipeline
Check failure on line 177 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator.go
GitHub Actions / lint
Check failure on line 114 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator_test.go
GitHub Actions / lint
Check failure on line 115 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator_test.go
GitHub Actions / lint
Check failure on line 116 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator_test.go
GitHub Actions / lint
Check failure on line 145 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator_test.go
GitHub Actions / lint
Check failure on line 146 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator_test.go
GitHub Actions / lint
Check failure on line 147 in cmd/jaeger/internal/processors/dependencyprocessor/aggregator_test.go
GitHub Actions / lint