Skip to content
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 2 commits into from
Jan 4, 2022

Conversation

embray
Copy link
Contributor

@embray embray commented Oct 29, 2021

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).

embray added a commit to embray/amqp-mock that referenced this pull request Nov 2, 2021
topic/header exchanges can be left as a separate exercise

depends on tsv1#8
and tsv1#9
@embray embray mentioned this pull request Nov 2, 2021
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 embray force-pushed the embray/bind-queue-to-exchange branch from 8b088af to 9803336 Compare November 8, 2021 15:48
@embray
Copy link
Contributor Author

embray commented Nov 8, 2021

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 tsv1 merged commit 9803336 into tsv1:master Jan 4, 2022
moyiz pushed a commit to moyiz/amqp-mock that referenced this pull request Nov 8, 2023
topic/header exchanges can be left as a separate exercise

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants