-
-
Notifications
You must be signed in to change notification settings - Fork 244
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
Race condition in Azure Service Bus queue #43
Comments
Could use the new |
@niemyjski yeah I'm with you on that. I'd rather replace |
|
Is this still an issue? |
Yeah - it's different from #45 (another race condition in |
It is an issue, but I don't know if it can be solved without using locks everywhere. I think the "correct" solution is to document that it's a dangerous method and shouldn't be used in multi-threaded environments. Once one part of your application determines the queue should be deleted, the rest of the application should be halted. |
@moswald would you mind updating the docs for this? |
As mentioned by @moswald in #38 ...
EnqueueAsync()
and Thread B callsDeleteQueueAsync()
EnsureQueueCreatedAsync()
, ensuring_queueClient
is not null_queueClient
to null_queueCleint
which is now nullThere's not really a nice way to handle this without locking. Couple of solutions:
Option 1
Wrap
_queueClient
in a property which throws a slightly different exception, leaving the user to retry.Option 2
Implement retry logic (preferably in
QueueBase
).The text was updated successfully, but these errors were encountered: