-
Notifications
You must be signed in to change notification settings - Fork 3.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
Add a new local random exchange type. #10091
Conversation
806597e
to
871d65c
Compare
bee073b
to
275a3fe
Compare
1c28c8c
to
71d3017
Compare
1fec4d4
to
f14a10e
Compare
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 testing I had troubles because the routing key must be empty, and I didn't know how to specify that in how I ran perf-test (long story). I managed to test thanks to kura. But perhaps the routing key should be ignored instead of forced empty? Like fanout. Just a suggestion, I don't have strong feelings either way.
All good otherwise!
So the binding key is validated to be empty as then we get the fastest routing query with khepri. |
8e7bd20
to
663aa35
Compare
b660ffd
to
8074788
Compare
This exchange type will only bind classic queues and will only return routes for queues that are local to the publishing connection. If more than one queue is bound it will make a random choice of the locally bound queues. This exchange type is suitable as a component in systems that run highly available low-latency RPC workloads. Co-authored-by: Marcial Rosales <[email protected]>
8074788
to
cca64e8
Compare
Co-authored-by: Marcial Rosales [email protected]
This exchange type will only bind classic queues and will only return routes for queues that are local to the publishing connection. If more than one queue is bound it will make a random choice of the locally bound queues.
This exchange type is suitable as a component in systems that run highly available low-latency RPC workloads.
Fixes #8334