-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Remove queue.Consumer #31502
Remove queue.Consumer #31502
Conversation
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
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.
LGTM, code seems clearer after this 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.
Yay, looks good to me, with what queue knowledge I have.
…s actually did check the result
This pull request is now in conflicts. Could you fix it? 🙏
|
What does this PR do?
Removes the
queue.Consumer
interface, and replaces itsGet
call with one directly on the queue interface itself.Why is it important?
The current Beats queue interface defines a notion of a "consumer" targeting a queue, and which is the exclusive object through which the queue can be read. There can be an arbitrary number of consumers operating in parallel, which can be closed independently of the queue and of each other.
Supporting the queue consumer interface and its current implementations is an obstacle to many planned changes, particularly elastic/elastic-agent-shipper#27 where we are trying to propagate consistent ordered event IDs through all queue types.
While we could use more complicated workarounds to support this regardless, there are good reasons to instead remove the concept of a queue consumer entirely:
queue.Producer
, the consumer has no special configuration of its own that affects its behavior, which means it's questionable whether there's any advantage to creating multiple consumers (as opposed to calling directly into the queue from multiple goroutines).This PR should functionally be a no-op; the only functional change is that certain places that used to pass a queue consumer now pass the queue itself instead.
Checklist
I have made corresponding changes to the documentationI have made corresponding change to the default configuration filesCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.