-
Notifications
You must be signed in to change notification settings - Fork 594
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
Autorecovery for server-named queues loops indefinitely when consumer listen this queue #1238
Milestone
Comments
stukselbax
changed the title
Autorecovery for server-named queues loops indefinitely
Autorecovery for server-named queues loops indefinitely when consumers listen this queue
Aug 16, 2022
stukselbax
changed the title
Autorecovery for server-named queues loops indefinitely when consumers listen this queue
Autorecovery for server-named queues loops indefinitely when consumer listen this queue
Aug 16, 2022
You have missed one crucial piece of information: what version of the client is used. |
If you understand what the issue is, you are welcome to submit a PR. |
I'm going to see if there's a reasonably simple fix. The obvious work-around is to change your code to NOT use the empty string when consuming: var consumerTag = channel.BasicConsume(
queueDeclareOk.QueueName,
false,
Guid.NewGuid().ToString("N", CultureInfo.InvariantCulture),
true,
true,
null,
new AsyncDefaultBasicConsumer(channel)); |
lukebakken
added a commit
that referenced
this issue
Mar 23, 2023
Fixes #1238 * Add failing test * Fix `RecordedConsumer` to allow the empty string for a queue name
lukebakken
added a commit
that referenced
this issue
Mar 23, 2023
Fixes #1238 * Add failing test * Fix `RecordedConsumer` to allow the empty string for a queue name * Add `CurrentQueue` to `IModel` to keep track of the last declared queue name as defined in the AMQP 091 spec * Fix `RecordedConsumer` to use `CurrentQueue` when passed in name is `string.Empty` Fixup API Approval
lukebakken
added a commit
that referenced
this issue
Mar 23, 2023
Port of #1324 to main Fixes #1238 * Add failing test * Fix `RecordedConsumer` to allow the empty string for a queue name * Add `CurrentQueue` to `IChannel` to keep track of the last declared queue name as defined in the AMQP 091 spec * Fix `RecordedConsumer` to use `CurrentQueue` when passed in name is `string.Empty` * Fixup API Approval
Fixed by #1324 |
@stukselbax the fix for this issue will ship in version |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using autorecovery connection which listens the server-named autodelete queue, and the process of connection autorecovery starts, it will never ends.
RabbitMQ.Client version: 6.4.0
Here minimalistic console application where problem can be reproduced
CODE
when it runs, make network between this app and rabbitmq server disconnected. For example, when running rabbitmq using docker, you can run the following commands:
After this steps it is expected that connection, with consumers and topology, will be recovered successfully.
Actually, recovery process didn't complete, because of consumer recovery error:
Stack trace
The possible root cause is that
RecordedConsumer
stores""
queue name when trying to call BasicConsume. When queues are recovering, an attempt is made to change consumers queue names. ButRecordedQueue
stores server-generated name. As the result, the name of queue inRecordedConsumer
didn't changed - it still stores""
, which leads to 404 error, because it didn't exists.The text was updated successfully, but these errors were encountered: