Upgrade to RabbitMQ 7 #34
Conversation
| @@ -1,7 +1,7 @@ | |||
| <Project ToolsVersion="15.0"> | |||
|
|
|||
| <PropertyGroup> | |||
| <TargetFrameworks>netstandard2.0</TargetFrameworks> | |||
| <TargetFrameworks>netstandard2.1</TargetFrameworks> | |||
There was a problem hiding this comment.
Needed for IAsyncDisposable (unless we add a nuget package ref)
| _factory = new ConnectionFactory | ||
| { | ||
| Uri = new Uri(options.ConnectionString), | ||
| AutomaticRecoveryEnabled = true, | ||
| DispatchConsumersAsync = true |
There was a problem hiding this comment.
This was removed and added to IConnection but looking through all the rabbit code I don't see any usages or how to set this.
| await _subscriberChannel.DisposeAsync().AnyContext(); | ||
| await _subscriberConnection.DisposeAsync().AnyContext(); |
There was a problem hiding this comment.
Dispose will automatically look at if it's open and call abort without throwing. I've updated all usages of the code to call this instead.
niemyjski
force-pushed
the
feature/rabbitmq7
branch
from
b07ddba to
597a23c
Compare
| GC.SuppressFinalize(this); | ||
| } | ||
|
|
||
| public async ValueTask DisposeAsync() |
There was a problem hiding this comment.
Followed this pattern https://alistairevans.co.uk/2019/10/24/net-asynchronous-disposal-tips-for-implementing-iasyncdisposable-on-your-own-types/ as well as what was happening in the rabbit client
| _publisherModel.Abort(); | ||
| _publisherModel.Dispose(); | ||
| _publisherModel = null; | ||
| _publisherChannel.Dispose(); |
There was a problem hiding this comment.
I implemented this twice due to a lot less async/sync mix. Their dispose under the hood is now doing GetAwaiter().GetResult() but only if it's open, the rest is sync.
| if (_logger.IsEnabled(LogLevel.Information)) _logger.LogInformation(ex, "Not able to create x-delayed-type exchange"); | ||
| success = false; | ||
| } | ||
| _logger.LogInformation(ex, "Unable to create x-delayed-type exchange: {Message}", ex.Message); |
There was a problem hiding this comment.
There is a bug here where success could be true even though it threw an exception which I think is wrong. I can change this back. But if it can't be thrown in the lasted rabbit 4.x the status reply code is 406. I'm not sure why it changed but this seems like a safer implementation.
Looks like this client release may have a lot of performance gains which we should monitor
Followed https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/main/v7-MIGRATION.md