Calls to CloseAsync on ServiceBusProcessor takes quite a lot of time to complete.

[EnricoMassone]

Hi,

I'm rewriting some code originally written by using the Microsoft.Azure.ServiceBus version 5.1.0, in order to adopt the new Azure.Messaging.ServiceBus package version 7.1.0.

As documented here we are using the CloseAsync method in order to dispose instances of the ServiceBusProcessor class.

We have noticed that these calls to CloseAsync take quite a long time to complete: something like 1 minute or so.

As a consequence, the shutdown time of our application is now much longer than before (compared to the time required when we employed the Microsoft.Azure.ServiceBus package under the hood).

Why is that ? Is that expected ? Am I missing anything ?

Thanks for helping.

[EnricoMassone]

Is this related to #17734 ?

[JoshLove-msft]

Hi @EnricoMassone, yes this is essentially the same issue. We are investigating potential solutions to improve the experience.

[EnricoMassone]

Hi @EnricoMassone, yes this is essentially the same issue. We are investigating potential solutions to improve the experience.

Thanks. I'm going to perform some tests inside kubernetes. I still have to fully understand the impact implied by hosting the application in kubernetes having longer shutdown time.

For the time being I would prefer to avoid the workaround you suggested here of tweaking the TryTimeout inside of RetryOptions. I'm afraid that doing so will impact all the operations and I'm not able to fully understand all the possible implications.

Can we expect a new release of Azure.Messaging.ServiceBus addressing this issue in the upcoming months ?

Thanks for helping.

[jsquire]

Hi @EnricoMassone. Thank you for your feedback and we regret that you're experiencing difficulties.

When stopping, the processor will attempt to gracefully shut down the tasks responsible for processing the associated entity. As you'd expect, a key part of the processing flow involves interacting with the Service Bus service. Unfortunately, service communication uses a timeout-based transport which does not honor cancellation. The RetryOptions.TryTimeout from the ServiceBusClientOptions used to create the ServiceBusClient controls the service operation timeout, and has a default of 60 seconds.

Though the processor itself will honor the cancellation token that a stop request signals, stopping may take up to the service operation timeout depending on where in the flow of logic each the processor is when the stop is requested. Because of the lack of cancellation support at the transport level, there is no way to provide a clean shutdown without waiting for any outstanding service calls to return.

As @JoshLove-msft mentioned, this is certainly not an ideal scenario nor is it the experience that we'd like to provide for the SDK. Unfortunately, in the short term, we're bound by the limitations of the transport and will be looking at ways to potentially mitigate. #19306 tracks this investigation. The long term solution will be working with the service team to find an approach to achieve cancellation support within the AMQP transport. Unfortunately, there's no timeline yet established.

I'm going to close this as a duplicate of #17734, as both are discussing the same topic, and there is some additional community conversation there. Please feel free to participate in that conversation; we're happy to continue discussing there and to help as we're able.