-
Notifications
You must be signed in to change notification settings - Fork 55
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
Connection recovery not working #230
Comments
This is a glaring bug in a most critical piece of .Net Isolated now that Durable Queues are no longer used. See a suggested solution in #227 (comment) Barring that, one non-optimal workaround until this is fixed (and maybe even useful afterwards). Then you can configure your AZ function in Azure Portal to the healthcheck path "/api/healthcheck" so it restarts if you run out of consumers.
Limitations: The health check will only fail if you completely run out of consumers, so if you have multiple instances of your function running and in some unlikely event multiple consumers disconnect but one remains connected, the function will not restart, and you will see reduced throughput. For more info on healthchecks in general: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-9.0 Program.cs
RabbitMqExtensions.cs
RabbitMqHealthCheck.cs
EsbOptions:
|
Dear developers,
we are using the rabbitmq trigger for an azure function (python) where we connect to a third-party rabbitmq instance to receive messages from a queue but do not have permission to publish to the queue (we have no access to the exchange).
We observe the following behaviour:
RabbitMQ.Client.Exceptions.AlreadyClosedException: Already closed: The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=403, text='ACCESS_REFUSED - access to exchange 'xxxx' in vhost 'xxxxx' refused for user 'xxxxx'', classId=60, methodId=40
So far so good. But now the rabbitmq trigger does not try to reconnect to the broker and retrieval of messages is stopped until we restart the function app.
We then wrapped everything into a try-except block to avoid any failing event-processings, which basically disables retry.
Is there any setting to disable the retry behaviour in the settings of the trigger?
In the source code of the listener, the following stackoverflow is mentioned in which an updated answer mentions quorum queue behaviour. Maybe that is worth implementing so
Why did the Listener not reconnect after the connection was closed? What would happen if there are any network problems? Is there any setting to enable auto reconnections?
Thank you for your help & time!
The text was updated successfully, but these errors were encountered: