[BUG] Azure Service Bus Timeout instead of correct response: MessagingEntityNotFound about azure-sdk-for-net

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jsquire]

@michael-eckhart-woellkart : By service contract, the Service Bus service will return a MessagingEntityNotFound response if a queue does not exist. The client reflects this error. In your case, you are seeing timeouts because the client was unable to create a connection, authorize, create an AMQP link, and send the data within the 10 seconds that you provided when overriding the default TryTimeout.

As a result, the end-to-end service operation did not complete, the service did not send its error response, and the client was therefore unable to observe and surface it. To verify the behavior, I'd suggest testing without changing the default TryTimeout and using a single ServiceBusSender instance.

[github-actions]

Hi @michael-eckhart-woellkart. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[michael-eckhart-woellkart]

Hi @jsquire, thanks for the very fast response.
I just put the timeout to 10 seconds for testing, productive we use the default timeout and still have this issue (there we have more queues) and I think it should not be normal that checking if there is a queue takes more then 30 seconds.

One ServiceBusSender does not work, as the ServiceBusSender is only for one queue, and we have a lot of different queues.

[michael-eckhart-woellkart]

/unresolve

[jsquire]

@michael-eckhart-woellkart: You're sharing one connection across all of your senders, which is going to cause queueing of traffic to occur. You're also starting a large number of background processes, each of which are highly asynchronous and need to be scheduled. As there are no fairness guarantees with thread pool scheduling, it is possible that some of these will be waiting for a while. Much depends on your host environment. All of this is unrelated to the Azure SDK packages - it's how the .NET runtime and network stack work.

Depending on the state of your network, potential transient errors, and similar, it can sometimes take 30-60 seconds to establish the connection, perform auth, open an AMQP link, and complete a service operation. Given that your sample shares a connection, all of your senders are blocked on the first two steps completing, and then they'll race to complete the latter two. All of those stages are highly asynchronous and will be fighting for time to complete.

As stated, to test the base error condition, use a single sender pointed at a queue that does not exist and use the default TryTimeout.

With respect to your scenario, if you are seeing timeouts that indicates that you are trying to do too much at once and the TryTimeout is inadequate due to your high degree of concurrency. To mitigate this, I'd suggest either revising your implementation to control concurrency to a degree that is appropriate for your host environment or upping the TryTimeout to a value that allows all of those concurrent operations to complete.

[github-actions]

Hi @michael-eckhart-woellkart. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[github-actions]

Hi @michael-eckhart-woellkart, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.