-
Notifications
You must be signed in to change notification settings - Fork 9
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
allow binding a queue to an exchange #9
Merged
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
Closed
embray
added a commit
to embray/amqp-mock
that referenced
this pull request
Nov 2, 2021
This fixes a tricky bug which can occur especially if there are two open channels on the same connection, though it might be possible to reproduce even on a single channel (needs a simpler test if we can figure out how). The main issue is that the delivery tags used for publisher confirmation and delivery confirmation are *not* the same, and should use different sequences. For example when a client publishes a message with delivery confirmation expected, it waits for a (n)ack with the matching delivery tag. That means the mock server needs to send a (n)ack with the correct delivery tag. However, if the client is acting as a consumer, and server is expecting delivery confirmation, then the server must exect a (n)ack from the client with a matching delivery_tag. In other words, the server needs to keep track of two separate sequences of delivery tags: one where the server is acting as a publisher, and one where it's handling a consumer. The delivery tags are also channel-specific, so this adds keying by channel for the delivery tags. (NOTE: I wrote this fix many months ago but never wrote up a proper description of it until now, so I'm not 100% sure my description of the problem is accurate.) Depends on tsv1#8 and tsv1#9
embray
added a commit
to embray/amqp-mock
that referenced
this pull request
Nov 2, 2021
This fixes a tricky bug which can occur especially if there are two open channels on the same connection, though it might be possible to reproduce even on a single channel (needs a simpler test if we can figure out how). The main issue is that the delivery tags used for publisher confirmation and delivery confirmation are *not* the same, and should use different sequences. For example when a client publishes a message with delivery confirmation expected, it waits for a (n)ack with the matching delivery tag. That means the mock server needs to send a (n)ack with the correct delivery tag. However, if the client is acting as a consumer, and server is expecting delivery confirmation, then the server must exect a (n)ack from the client with a matching delivery_tag. In other words, the server needs to keep track of two separate sequences of delivery tags: one where the server is acting as a publisher, and one where it's handling a consumer. The delivery tags are also channel-specific, so this adds keying by channel for the delivery tags. (NOTE: I wrote this fix many months ago but never wrote up a proper description of it until now, so I'm not 100% sure my description of the problem is accurate.) Depends on tsv1#8 and tsv1#9
Previously, publishing a message to an exchange (either through the mock client, or through a "real" client connected to the mock server) would not result in that message being added to any queues bound to the exchange. Testing queues and exchanges were totally separate. E.g. for the same effect you would have to have a "real" client publish to an exchange, and have the mock client publish to an associated queue. This automatically adds any messages published to an exchange to any queues bound to that exchange (this assumes direct routing--fanout will be added in a follow-up).
declare_queue now actually does something, in terms of ensuring that the queue exists new queues are automatically bound to the default exchange
embray
force-pushed
the
embray/bind-queue-to-exchange
branch
from
November 8, 2021 15:48
8b088af
to
9803336
Compare
Rebased. |
embray
added a commit
to embray/amqp-mock
that referenced
this pull request
Nov 8, 2021
This fixes a tricky bug which can occur especially if there are two open channels on the same connection, though it might be possible to reproduce even on a single channel (needs a simpler test if we can figure out how). The main issue is that the delivery tags used for publisher confirmation and delivery confirmation are *not* the same, and should use different sequences. For example when a client publishes a message with delivery confirmation expected, it waits for a (n)ack with the matching delivery tag. That means the mock server needs to send a (n)ack with the correct delivery tag. However, if the client is acting as a consumer, and server is expecting delivery confirmation, then the server must exect a (n)ack from the client with a matching delivery_tag. In other words, the server needs to keep track of two separate sequences of delivery tags: one where the server is acting as a publisher, and one where it's handling a consumer. The delivery tags are also channel-specific, so this adds keying by channel for the delivery tags. (NOTE: I wrote this fix many months ago but never wrote up a proper description of it until now, so I'm not 100% sure my description of the problem is accurate.) Depends on tsv1#8 and tsv1#9
tsv1
added a commit
that referenced
this pull request
Nov 19, 2023
* allow binding a queue to an exchange Previously, publishing a message to an exchange (either through the mock client, or through a "real" client connected to the mock server) would not result in that message being added to any queues bound to the exchange. Testing queues and exchanges were totally separate. E.g. for the same effect you would have to have a "real" client publish to an exchange, and have the mock client publish to an associated queue. This automatically adds any messages published to an exchange to any queues bound to that exchange (this assumes direct routing--fanout will be added in a follow-up). * two more enhancements concerning queues and exchanges: declare_queue now actually does something, in terms of ensuring that the queue exists new queues are automatically bound to the default exchange * add support for fanout exchanges topic/header exchanges can be left as a separate exercise depends on #8 and #9 * fix linter * add tests * Change storage history from dict to list to support multiple copies of the same message with fanout exchanges * Change test_routing_fanout_exchange to test that bound queues receive message regardless of routing key * Remove python3.7 support --------- Co-authored-by: E. Madison Bray <erik.bray@lri.fr> Co-authored-by: Nikita Tsvetkov <nikitanovosibirsk@yandex.com>
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.
Previously, publishing a message to an exchange (either through the mock
client, or through a "real" client connected to the mock server) would
not result in that message being added to any queues bound to the
exchange. Testing queues and exchanges were totally separate. E.g. for
the same effect you would have to have a "real" client publish to an
exchange, and have the mock client publish to an associated queue.
This automatically adds any messages published to an exchange to any
queues bound to that exchange (this assumes direct routing--fanout
will be added in a follow-up).