ANN Breaking changes in RabbitMQ .NET client 3.5.0
807 views
Skip to first unread message
Michael Klishin
Mar 8, 2015, 5:11:16 PM3/8/15
to rabbitm...@googlegroups.com, easy...@googlegroups.com
RabbitMQ 3.5.0 is around the corner now and
I'd like to announce a few backwards-incompatible changes in RabbitMQ .NET client 3.5.0.
## Custom Delegates Replaced with Standard Generic Types
In 3.4.x, and for most of the history of the client, various events were using
delegate/handler types that had virtually identical signatures:
* BasicReturnEventHandler
* BasicAckEventHandler
* BasicNackEventHandler
* RecoveryEventHandler
* ConnectionShutdownEventHandler
* ModelShutdownEventHandler
* CallbackExceptionEventHandler
* FlowControlEventHandler
* BasicRecoverOkEventHandler
The only thing that was different was event arguments type. This solution made sense in 2007
when the client was first created but not in 2015. In 3.5.0, we've replaced those types with
EventHandler<T>, e.g. EventHandler<ConnectionBlockedEventArgs>.
In a few places handlers were replaced with Action<T>, Action<T1, T2>, Func<T1, T2>,
and so on.
## Concurrent Consumer Operation Dispatch
Previously the client dispatched all incoming protocol methods (e.g. basic.deliver
or basic.cancel or basic.consume-ok) on the I/O thread. Not only this isn't
particularly efficient on modern multi-core systems, this had profound limitations
on what IModel methods were safe to use from consumer event handlers.
In 3.5.0, consumer operations are dispatched concurrently. The client will preserve the order
in which methods are dispatched on individual channels. Connection-wide, the ordering is not
guaranteed.
It is possible to provide a custom TaskScheduler to control degree of concurrency (e.g. go back
to the single-threaded dispatch implementation from earlier versions) and integrate better
with your consumer code that may already use TPL with custom scheduler(s).
## Heavier Use of Properties
Many classes in the client used to use properties intermixed with "regular" methods that imitated
get-only properties. Most of such sites now use auto-implemented properties.
## Minimum Required .NET Version
The client now requires .NET 4.0.
## Minimum Required Visual Studio Version
For those looking to contribute or read the code, the client now requires Visual
Studio 2013 (Community Edition works great) or later.
## What to Expect in 3.6.0
RabbitMQ engineers care about backwards compatibility but .NET client badly needed
modernisation. Now that we have mostly caught up with .NET 4.0, we can explore
how the features it provides (e.g. the TPL) can be integrated into the client's API.
In addition, our users ask for features such as Windows RT support. [1]
This may mean more breaking changes. We'll try to keep things compatible but making
it easier (or possible) to use the client in the modern .NET ecosystem is an even
higher priority.
After the 3.5.0 release, RabbitMQ development takes one more step to being
entirely done on Github: we switch to GitHub issues and use pull requests as our
primary way of submitting changes.
This means it is easier than ever for you to participate, report bugs, ask for
features you'd like to see and contribute code.
The repository is at https://github.com/rabbitmq/rabbitmq-dotnet-client.
1. https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/16
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
I'd like to announce a few backwards-incompatible changes in RabbitMQ .NET client 3.5.0.
## Custom Delegates Replaced with Standard Generic Types
In 3.4.x, and for most of the history of the client, various events were using
delegate/handler types that had virtually identical signatures:
* BasicReturnEventHandler
* BasicAckEventHandler
* BasicNackEventHandler
* RecoveryEventHandler
* ConnectionShutdownEventHandler
* ModelShutdownEventHandler
* CallbackExceptionEventHandler
* FlowControlEventHandler
* BasicRecoverOkEventHandler
The only thing that was different was event arguments type. This solution made sense in 2007
when the client was first created but not in 2015. In 3.5.0, we've replaced those types with
EventHandler<T>, e.g. EventHandler<ConnectionBlockedEventArgs>.
In a few places handlers were replaced with Action<T>, Action<T1, T2>, Func<T1, T2>,
and so on.
## Concurrent Consumer Operation Dispatch
Previously the client dispatched all incoming protocol methods (e.g. basic.deliver
or basic.cancel or basic.consume-ok) on the I/O thread. Not only this isn't
particularly efficient on modern multi-core systems, this had profound limitations
on what IModel methods were safe to use from consumer event handlers.
In 3.5.0, consumer operations are dispatched concurrently. The client will preserve the order
in which methods are dispatched on individual channels. Connection-wide, the ordering is not
guaranteed.
It is possible to provide a custom TaskScheduler to control degree of concurrency (e.g. go back
to the single-threaded dispatch implementation from earlier versions) and integrate better
with your consumer code that may already use TPL with custom scheduler(s).
## Heavier Use of Properties
Many classes in the client used to use properties intermixed with "regular" methods that imitated
get-only properties. Most of such sites now use auto-implemented properties.
## Minimum Required .NET Version
The client now requires .NET 4.0.
## Minimum Required Visual Studio Version
For those looking to contribute or read the code, the client now requires Visual
Studio 2013 (Community Edition works great) or later.
## What to Expect in 3.6.0
RabbitMQ engineers care about backwards compatibility but .NET client badly needed
modernisation. Now that we have mostly caught up with .NET 4.0, we can explore
how the features it provides (e.g. the TPL) can be integrated into the client's API.
In addition, our users ask for features such as Windows RT support. [1]
This may mean more breaking changes. We'll try to keep things compatible but making
it easier (or possible) to use the client in the modern .NET ecosystem is an even
higher priority.
After the 3.5.0 release, RabbitMQ development takes one more step to being
entirely done on Github: we switch to GitHub issues and use pull requests as our
primary way of submitting changes.
This means it is easier than ever for you to participate, report bugs, ask for
features you'd like to see and contribute code.
The repository is at https://github.com/rabbitmq/rabbitmq-dotnet-client.
1. https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/16
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
Mike Hadlow
Mar 9, 2015, 11:30:49 AM3/9/15
to easy...@googlegroups.com, rabbitm...@googlegroups.com
Many thanks Michael. Looking forward to the 3.5 release.
On Mon, Mar 9, 2015 at 3:12 PM, Юрий Плинер <yury....@gmail.com> wrote:
Thank you for announcement, Michael.We will keep in touch and update client as soon as possible.
понедельник, 9 марта 2015 г., 2:41:10 UTC+5:30 пользователь Michael Klishin написал:
--
You received this message because you are subscribed to the Google Groups "EasyNetQ" group.
To unsubscribe from this group and stop receiving emails from it, send an email to easynetq+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrey Kuznetsov
Mar 12, 2015, 1:49:46 AM3/12/15
to rabbitm...@googlegroups.com, easy...@googlegroups.com
It is possible to provide a custom TaskScheduler to control degree of concurrency (e.g. go back
to the single-threaded dispatch implementation from earlier versions) and integrate better
with your consumer code that may already use TPL with custom scheduler(s).
From the code it looks like, that ConsumerWorkService is THE class for dispatching
The trouble is I can't understand how can the behavior of service depends on different TaskScheduler passed to constructor if it never used in body of any methods.
And tasks that created in code are started with Start() and not with Start(TaskScheduler)
Michael Klishin
Mar 12, 2015, 8:59:40 AM3/12/15
to rabbitm...@googlegroups.com, Andrey Kuznetsov, easy...@googlegroups.com
On 12 March 2015 at 08:49:48, Andrey Kuznetsov (akuzn...@gmail.com) wrote:
> The trouble is I can't understand how can the behavior of service
> depends on different TaskScheduler passed to constructor if
> it never used in body of any methods.
> And tasks that created in code are started with Start() and not
> with Start(TaskScheduler)
Your observation is correct.
> The trouble is I can't understand how can the behavior of service
> depends on different TaskScheduler passed to constructor if
> it never used in body of any methods.
> And tasks that created in code are started with Start() and not
> with Start(TaskScheduler)
Fixed and will be in 3.5.1 as well as tomorrow's nightly builds:
https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/40
Reply all
Reply to author
Forward
0 new messages