Reconnection failed on auto-delete queue

[stevenxi]

Re-attach consumer to auto-delete queues fails. The reason is it uses the queue name to consume but the auto-delete queues are not exist anymore.

Solution: what I did in my application is created a wrapper around AdvancedBus, also a wrapper to the consumer (IDisposable). On a reconnected event, it recreate those queues. But I'm not sure how to merge to EasyNetQ.

[zidad]

@stevenxi is this still an issue? Is there a way this is reproducible using a unit test?

[stevenxi]

This patch doesn't in fact fix the problem, but provide a way to recover from the failure status. Previously, once failed, the consumer all die.

I don't think it's unit testable, the failure is mainly involved from the RabbitMQ's native behavior[TBC].

On Thu, Feb 11, 2016 at 10:47 AM, Wiebe Tijsma [email protected] wrote:

@stevenxi https://github.com/stevenxi is this still an issue? Is there a way this is reproducible using a unit test?

— Reply to this email directly or view it on GitHub https://github.com/EasyNetQ/EasyNetQ/issues/330#issuecomment-182806403.

[zidad]

Ok thanks for the info. It probably should redeclare the queues on reconnect. Could you consider using queues with a (short) expiration instead of auto-delete queues? That means they won't be immediately deleted as soon as the connection drops briefly.

[stevenxi]

The change I've updated to the GitHub is just a simple fix. And this fix is more about errors on writing underlying stream, rather than disconnect/reconnect.

In the real usage, I did my own wrapper above the EasyNetQ, it will reclaim the auto-delete queues when reconnect. I would recommend you do it as well. I don't think I would have enough time to update/contribute to the EasyNetQ code base for the moment.

On Thu, Feb 11, 2016 at 1:56 PM, Wiebe Tijsma [email protected] wrote:

Ok thanks for the info. It probably should redeclare the queues on reconnect. Could you consider using queues with a (short) expiration instead of auto-delete queues? That means they won't be immediately deleted as soon as the connection drops briefly.

— Reply to this email directly or view it on GitHub https://github.com/EasyNetQ/EasyNetQ/issues/330#issuecomment-182875372.

[mebymyself]

@stevenxi, I am experiencing same issue. Can you please share the wrapper you created? Thanks

[stevenxi]

@mebymyself https://gist.github.com/stevenxi/ed150b482b8c87b41f67e3c7e53973ff I've removed bit unnecessary code, so you may need to fix the build. The you can use Lazy in place of TenaciousLazy<T>. The TenaciousLazy is just a try-catch enabled Lazy<T>.

[Jmaharman]

@stevenxi - thanks for your wrapper, I've tried to reverse engineer the BindingWrapper but I'm at a loss what _pendingConsumer is for? And is that another BindingWrapper, or some other class not relevant to the above issue?

[stevenxi]

@Jmaharman That was relate to a special need of our project, so I removed most part of, but forgot remove the line you saw.

In most of case, you won't need this. Just remove those redundant lines.

It is for a "Multiple consumer binding", I have a pull request for this: https://github.com/EasyNetQ/EasyNetQ/pull/628

[EduardoPires]

I have a problem reconnecting after RabbitMQ restart (I´m using request/response pattern) My responder can´t receive the messages after restart.

There is a solution?

[Pliner]

Hi @EduardoPires,

I will look at this issue tomorrow. Anyway, could you please describe the scenario as detailed as possible?

[EduardoPires]

@Pliner sure!

I´m integrating ASP.NET Core APIs by EasyNetQ and running RabbitMQ as docker container.

I have a BackgroundService (.NET HostedService) registered as Singleton. In this background service I have a Responder:

protected override Task ExecuteAsync(CancellationToken stoppingToken) { _bus.RespondAsync<UsuarioRegistradoIntegrationEvent, ResponseMessage>(async request => await RegistrarCliente(request)); return Task.CompletedTask; }

Request and Response messages works good, but if I restart the RabbitMQ container my application stop to receive requests at background service.

My application can send the request message (I can see on rabbitmq) but I get an EasyNetQException about correlation id. The message isn't delivered to my responder running at background service.

I think the application lost some bind or route using easynetq (and request response pattern) when RabbitMQ restarts.

[Pliner]

@Pliner sure!

I´m integrating ASP.NET Core APIs by EasyNetQ and running RabbitMQ as docker container.

I have a BackgroundService (.NET HostedService) registered as Singleton. In this background service I have a Responder:

protected override Task ExecuteAsync(CancellationToken stoppingToken) { _bus.RespondAsync<UsuarioRegistradoIntegrationEvent, ResponseMessage>(async request => await RegistrarCliente(request)); return Task.CompletedTask; }

Request and Response messages works good, but if I restart the RabbitMQ container my application stop to receive requests at background service.

My application can send the request message (I can see on rabbitmq) but I get an EasyNetQException about correlation id. The message isn't delivered to my responder running at background service.

I think the application lost some bind or route using easynetq (and request response pattern) when RabbitMQ restarts.

It seems that the reason is the regression bug and it's not connected to the issue. Here is the PR https://github.com/EasyNetQ/EasyNetQ/pull/1060 with a fix.