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

async/await API #83

Open
michaelklishin opened this Issue May 3, 2015 · 54 comments

Comments

Projects
None yet
@michaelklishin
Member

michaelklishin commented May 3, 2015

Originally this issue was about enabling of message publishing with a natural future ("awaitable" in the .NET world) API.

After some discussions with the .NET community, it makes more sense for us to switch to async/await entirely. This is a major change. The users who cannot upgrade in the meantime will be able to use 3.6.x versions with future RabbitMQ releases.

The decision is to develop a completely new client oriented towards async/await, although #307 introduce it in a place where it makes most sense and can be done with relatively few breaking changes.

@michaelklishin michaelklishin self-assigned this May 3, 2015

@ngbrown

This comment has been minimized.

Show comment
Hide comment
@ngbrown

ngbrown Jul 7, 2015

Contributor

I think moving to an async API with Task returns is a good idea in general, the question is how is this going to be managed?

I've seen .NET libraries (e.g. MongoDB client) that go async do it in a way that splits the entire API into an old/new set of namespaces if not actual libraries (that need to be separately pulled from nuget). Generally, the non-async methods become wrappers for the async ones, thus the split.

Contributor

ngbrown commented Jul 7, 2015

I think moving to an async API with Task returns is a good idea in general, the question is how is this going to be managed?

I've seen .NET libraries (e.g. MongoDB client) that go async do it in a way that splits the entire API into an old/new set of namespaces if not actual libraries (that need to be separately pulled from nuget). Generally, the non-async methods become wrappers for the async ones, thus the split.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jul 7, 2015

Member

That's what we have in mind.

Member

michaelklishin commented Jul 7, 2015

That's what we have in mind.

@rasmus

This comment has been minimized.

Show comment
Hide comment
@rasmus

rasmus commented Oct 28, 2015

+1

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

Could I help out somehow?

Contributor

danielmarbach commented Jan 8, 2016

Could I help out somehow?

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

@danielmarbach a good way to start would be to look into how much effort it would be to have an async/await-oriented version of IModel and 2 implementations (recovery-aware and "regular" one). Then we can go on to implementing it. All development happens on GitHub in the open.

Member

michaelklishin commented Jan 8, 2016

@danielmarbach a good way to start would be to look into how much effort it would be to have an async/await-oriented version of IModel and 2 implementations (recovery-aware and "regular" one). Then we can go on to implementing it. All development happens on GitHub in the open.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

Should I do a spike then to see what is affected?

Am 08.01.2016 um 08:46 schrieb Michael Klishin notifications@github.com:

@danielmarbach a good way to start would be to look into how much effort it would be to have an async/await-oriented version of IModel and 2 implementations (recovery-aware and "regular" one). Then we can go on to implementing it. All development happens on GitHub in the open.


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 8, 2016

Should I do a spike then to see what is affected?

Am 08.01.2016 um 08:46 schrieb Michael Klishin notifications@github.com:

@danielmarbach a good way to start would be to look into how much effort it would be to have an async/await-oriented version of IModel and 2 implementations (recovery-aware and "regular" one). Then we can go on to implementing it. All development happens on GitHub in the open.


Reply to this email directly or view it on GitHub.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

@danielmarbach feel free. Thank you very much for your time!

Member

michaelklishin commented Jan 8, 2016

@danielmarbach feel free. Thank you very much for your time!

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

I do this the all-in way. No more sync APIs.

Am 08.01.2016 um 11:26 schrieb Michael Klishin notifications@github.com:

@danielmarbach feel free. Thank you very much for your time!


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 8, 2016

I do this the all-in way. No more sync APIs.

Am 08.01.2016 um 11:26 schrieb Michael Klishin notifications@github.com:

@danielmarbach feel free. Thank you very much for your time!


Reply to this email directly or view it on GitHub.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.

Member

michaelklishin commented Jan 8, 2016

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

Fine with me if you know what the consequences of this decision are:

Having two completely sep. code paths and therefore the potential of fixing one path and forgetting the other one

Am 08.01.2016 um 11:32 schrieb Michael Klishin notifications@github.com:

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 8, 2016

Fine with me if you know what the consequences of this decision are:

Having two completely sep. code paths and therefore the potential of fixing one path and forgetting the other one

Am 08.01.2016 um 11:32 schrieb Michael Klishin notifications@github.com:

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.


Reply to this email directly or view it on GitHub.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

See for example what we did

http://particular.net/blog/async-await-its-time

Am 08.01.2016 um 11:32 schrieb Michael Klishin notifications@github.com:

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 8, 2016

See for example what we did

http://particular.net/blog/async-await-its-time

Am 08.01.2016 um 11:32 schrieb Michael Klishin notifications@github.com:

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.


Reply to this email directly or view it on GitHub.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

@danielmarbach thank you for your perspective. RabbitMQ (and this client) is almost 9 years old. We understand the consequences of major changes, in client libraries and elsewhere. We also know very well what happens when you break things.

.NET client has two versions ("regular" and WinRT) that share effectively all unit tests, for example. So far so good.

Member

michaelklishin commented Jan 8, 2016

@danielmarbach thank you for your perspective. RabbitMQ (and this client) is almost 9 years old. We understand the consequences of major changes, in client libraries and elsewhere. We also know very well what happens when you break things.

.NET client has two versions ("regular" and WinRT) that share effectively all unit tests, for example. So far so good.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

Didn't want to imply that you guys are clueless or anything. Sorry if I sounded like a jerk.

I was talking about the implications on the team maintaining the lib not the breaking changes per se

Am 08.01.2016 um 11:41 schrieb Michael Klishin notifications@github.com:

@danielmarbach thank you for your perspective. RabbitMQ (and this client) is almost 9 years old. We understand the consequences of major changes, in client libraries and elsewhere. We also know very well what happens when you break things.

.NET client has two versions ("regular" and WinRT) that share effectively all unit tests, for example. So far so good.


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 8, 2016

Didn't want to imply that you guys are clueless or anything. Sorry if I sounded like a jerk.

I was talking about the implications on the team maintaining the lib not the breaking changes per se

Am 08.01.2016 um 11:41 schrieb Michael Klishin notifications@github.com:

@danielmarbach thank you for your perspective. RabbitMQ (and this client) is almost 9 years old. We understand the consequences of major changes, in client libraries and elsewhere. We also know very well what happens when you break things.

.NET client has two versions ("regular" and WinRT) that share effectively all unit tests, for example. So far so good.


Reply to this email directly or view it on GitHub.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

No offence taken. We understand that it will be a long and potentially difficult path to get to the new world where everybody uses .NET Core and only C# 5.0+ APIs. We definitely want to get our client there, just without disruptive upgrade-or-leave-it releases.

Also note that certain operations are synchronous by design in the protocol. This does not include publishing or consumption of messages, which is why the issue title only mentions publishing.

Member

michaelklishin commented Jan 8, 2016

No offence taken. We understand that it will be a long and potentially difficult path to get to the new world where everybody uses .NET Core and only C# 5.0+ APIs. We definitely want to get our client there, just without disruptive upgrade-or-leave-it releases.

Also note that certain operations are synchronous by design in the protocol. This does not include publishing or consumption of messages, which is why the issue title only mentions publishing.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

By "synchronous" above I mean semantics, not necessarily implementation, of course. Nobody's complained about the blocking nature of IModel.QueueDeclare or QueueBind in my memory, so perhaps those parts of the API make sense as they are.

Member

michaelklishin commented Jan 8, 2016

By "synchronous" above I mean semantics, not necessarily implementation, of course. Nobody's complained about the blocking nature of IModel.QueueDeclare or QueueBind in my memory, so perhaps those parts of the API make sense as they are.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

Fair enough. You'd have at least the change to base that decision on the shoulders of the whole ecosystem. Many OSS libs and IO bound libs are moving to async only. Just saying ;)

Am 08.01.2016 um 11:48 schrieb Michael Klishin notifications@github.com:

No offence taken. We understand that it will be a long and potentially difficult path to get to the new world where everybody uses .NET Core and only C# 5.0+ APIs. We definitely want to get our client there, just without disruptive upgrade-or-leave-it releases.

Also note that certain operations are synchronous by design in the protocol. This does not include publishing or consumption of messages, which is why the issue title only mentions publishing.


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 8, 2016

Fair enough. You'd have at least the change to base that decision on the shoulders of the whole ecosystem. Many OSS libs and IO bound libs are moving to async only. Just saying ;)

Am 08.01.2016 um 11:48 schrieb Michael Klishin notifications@github.com:

No offence taken. We understand that it will be a long and potentially difficult path to get to the new world where everybody uses .NET Core and only C# 5.0+ APIs. We definitely want to get our client there, just without disruptive upgrade-or-leave-it releases.

Also note that certain operations are synchronous by design in the protocol. This does not include publishing or consumption of messages, which is why the issue title only mentions publishing.


Reply to this email directly or view it on GitHub.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 8, 2016

Contributor

@michaelklishin See the effect a proper async implementation would have

#149

Contributor

danielmarbach commented Jan 8, 2016

@michaelklishin See the effect a proper async implementation would have

#149

@michaelklishin michaelklishin changed the title from "Awaitable" publishing with confirms to async/await API Jan 8, 2016

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 8, 2016

Member

I updated the issue to reflect the (greatly) extended scope of this issue.

Member

michaelklishin commented Jan 8, 2016

I updated the issue to reflect the (greatly) extended scope of this issue.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 9, 2016

Contributor

Here is a brain dump of a plan of attack:

  • Discuss high-level API and consider getting rid of work service in favour of channels if possible (might need a spike first)
  • Create up-for-grabs issues for indiviual section in the code which can be made async according to the high-level API decisions (to make the work parallizable), use GetAwaiter().GetResult() to isolate these work areas (async changes ripple through pretty quickly)
  • Bring all areas together and remove GetAwaiter().GetResult() calls

Goal:

  • Leave internal infrastructure/design intact if possible but make it async
  • Get rid of synchronous and asynchronous APIs (over events) and make them all Task based

Thoughts? Extensions? Corrections?

Contributor

danielmarbach commented Jan 9, 2016

Here is a brain dump of a plan of attack:

  • Discuss high-level API and consider getting rid of work service in favour of channels if possible (might need a spike first)
  • Create up-for-grabs issues for indiviual section in the code which can be made async according to the high-level API decisions (to make the work parallizable), use GetAwaiter().GetResult() to isolate these work areas (async changes ripple through pretty quickly)
  • Bring all areas together and remove GetAwaiter().GetResult() calls

Goal:

  • Leave internal infrastructure/design intact if possible but make it async
  • Get rid of synchronous and asynchronous APIs (over events) and make them all Task based

Thoughts? Extensions? Corrections?

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 9, 2016

Member

There are parts of the API that are naturally events, e.g. consumer cancellation or server-sent connection.close. Those should stay events in my opinion. Event-driven consumers also make sense.

Otherwise, sounds reasonable.

Member

michaelklishin commented Jan 9, 2016

There are parts of the API that are naturally events, e.g. consumer cancellation or server-sent connection.close. Those should stay events in my opinion. Event-driven consumers also make sense.

Otherwise, sounds reasonable.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 9, 2016

Contributor

Ok, but normal event handlers are a PITA with async. We need a better concept

Am 09.01.2016 um 14:42 schrieb Michael Klishin notifications@github.com:

There are parts of the API that are naturally events, e.g. consumer cancellation or server-sent connection.close. Those should stay events in my opinion. Event-driven consumers also make sense.

Otherwise, sounds reasonable.


Reply to this email directly or view it on GitHub.

Contributor

danielmarbach commented Jan 9, 2016

Ok, but normal event handlers are a PITA with async. We need a better concept

Am 09.01.2016 um 14:42 schrieb Michael Klishin notifications@github.com:

There are parts of the API that are naturally events, e.g. consumer cancellation or server-sent connection.close. Those should stay events in my opinion. Event-driven consumers also make sense.

Otherwise, sounds reasonable.


Reply to this email directly or view it on GitHub.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 9, 2016

Member

How would you handle things with async that can happen at any moment, and are not user-initiated?

Member

michaelklishin commented Jan 9, 2016

How would you handle things with async that can happen at any moment, and are not user-initiated?

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 24, 2016

Contributor

This shows how we could handle async events #151

Contributor

danielmarbach commented Jan 24, 2016

This shows how we could handle async events #151

@ngbrown

This comment has been minimized.

Show comment
Hide comment
@ngbrown

ngbrown Jan 27, 2016

Contributor

@danielmarbach Looking at the suggested code, I see a lot of functions that have only the return type changed. Do these functions need to be awaited? If so, then it will be difficult to find all of the points in client code to change without compile errors (especially the ones that used to be void). I recommend that most, if not all of the functions that are going to be asynchronous with a Task being returned should have their name changed to include Async (MethodNameAsync()).

This may also open the RabbitMQ client up to having a backward compatibility layer for the old synchronous style like MongoDB did when they moved their .NET client library to Async. They have a separate NuGet package that keeps the API the same as the old version, and translates to the new Async library.

Contributor

ngbrown commented Jan 27, 2016

@danielmarbach Looking at the suggested code, I see a lot of functions that have only the return type changed. Do these functions need to be awaited? If so, then it will be difficult to find all of the points in client code to change without compile errors (especially the ones that used to be void). I recommend that most, if not all of the functions that are going to be asynchronous with a Task being returned should have their name changed to include Async (MethodNameAsync()).

This may also open the RabbitMQ client up to having a backward compatibility layer for the old synchronous style like MongoDB did when they moved their .NET client library to Async. They have a separate NuGet package that keeps the API the same as the old version, and translates to the new Async library.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Jan 27, 2016

Contributor

Nathan, thanks for chiming in. As you highlighted this is an exploratory PR. The idea of the PR you reference is to explore ways to keep as much of the current design in place to not open a can of worms.

About the functions that need to be awaited. I assume you are talking from the end-user perspective. You are right when switching from void returning APIs to Task returning APIs (Task is the new void in the asynchronous world ;) ) this will lead to compiler errors. As you pointed out there is the possibility to obsolete current synchronous APIs and point in the obsoletion messages towards the new asynchronous APIs. In order to be able to do that those APIs need to be postfixed with Async. The benefit of this would that as you pointed out it would be possible to have a sync API and an async API side by side.

Over the last few months I was heavily involved in porting NServiceBus to a new asynchronous API. When we started on this journey we made the following decisions:

  • Since mixing blocking with asynchronous code is almost impossible from a library/framework perspective we would need to maintain two "identical" but totally seperate code paths for the synchronous APIs and the asynchronous APIs. The maintenance, documentation but also the "perceived complexity" costs for new users drove us to the conclusion that the only way forward is to bite the bullet and go all-in with an async-only API. We are well aware that this might cost us a few users or they stay forever on older versions of the API but this effect is totally independent of this change. Every change makes users (for whatever reason) to balance the risk vs benefits and eventually stay on an older version
  • Since almost very code path in NServiceBus is triggered or calls into an IO-bound problem domain almost all APIs (exception configuration..) became async. We then discussed the added benefit of the postfix Async and came to the conclusion that combined with the above decision it would only be noise on the APIs.
  • We bumped the major version of the library (of course because we try hard to follow semver)
  • We came to the conclusion there is no good way to introduce these breaking changes without making the code compilable all the time. We are trying hard to show in our upgrade guides scenarios the users could face and show migration scenarios in those guides.

I cannot speak for this community and can only suggest possible ways and talk from the trenches.

Taking into account the possibility to move to semver and decouple the client version from the server version this library could make a major version bump and then do the necessary evil breaking changes while leaving the 3.x versions on support branches and keep patching those where necessary / possible on the "legacy" sync APIs. No need for an additional nuget package in my humble opinion

Contributor

danielmarbach commented Jan 27, 2016

Nathan, thanks for chiming in. As you highlighted this is an exploratory PR. The idea of the PR you reference is to explore ways to keep as much of the current design in place to not open a can of worms.

About the functions that need to be awaited. I assume you are talking from the end-user perspective. You are right when switching from void returning APIs to Task returning APIs (Task is the new void in the asynchronous world ;) ) this will lead to compiler errors. As you pointed out there is the possibility to obsolete current synchronous APIs and point in the obsoletion messages towards the new asynchronous APIs. In order to be able to do that those APIs need to be postfixed with Async. The benefit of this would that as you pointed out it would be possible to have a sync API and an async API side by side.

Over the last few months I was heavily involved in porting NServiceBus to a new asynchronous API. When we started on this journey we made the following decisions:

  • Since mixing blocking with asynchronous code is almost impossible from a library/framework perspective we would need to maintain two "identical" but totally seperate code paths for the synchronous APIs and the asynchronous APIs. The maintenance, documentation but also the "perceived complexity" costs for new users drove us to the conclusion that the only way forward is to bite the bullet and go all-in with an async-only API. We are well aware that this might cost us a few users or they stay forever on older versions of the API but this effect is totally independent of this change. Every change makes users (for whatever reason) to balance the risk vs benefits and eventually stay on an older version
  • Since almost very code path in NServiceBus is triggered or calls into an IO-bound problem domain almost all APIs (exception configuration..) became async. We then discussed the added benefit of the postfix Async and came to the conclusion that combined with the above decision it would only be noise on the APIs.
  • We bumped the major version of the library (of course because we try hard to follow semver)
  • We came to the conclusion there is no good way to introduce these breaking changes without making the code compilable all the time. We are trying hard to show in our upgrade guides scenarios the users could face and show migration scenarios in those guides.

I cannot speak for this community and can only suggest possible ways and talk from the trenches.

Taking into account the possibility to move to semver and decouple the client version from the server version this library could make a major version bump and then do the necessary evil breaking changes while leaving the 3.x versions on support branches and keep patching those where necessary / possible on the "legacy" sync APIs. No need for an additional nuget package in my humble opinion

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jan 27, 2016

Member

@ngbrown good idea. We should take a look at what MongoDB did.

Member

michaelklishin commented Jan 27, 2016

@ngbrown good idea. We should take a look at what MongoDB did.

@pardahlman

This comment has been minimized.

Show comment
Hide comment
@pardahlman

pardahlman Jan 29, 2016

Contributor

This is a very interesting topic. Good job with the spike, @danielmarbach . I agree with @ngbrown; we should suffix the async method names with Async, which also is in line with naming conventions.

MongoDb is a good case study of a major framework implementing an async API. When they release 2.0 they only provided async methods, but recently they re-added sync methods to their API. They have a huge community, and I guess they had some long discussions before they decided on this. That, and the fact that it's nice to be backward compatible are two reasons for keeping the existing api.

Contributor

pardahlman commented Jan 29, 2016

This is a very interesting topic. Good job with the spike, @danielmarbach . I agree with @ngbrown; we should suffix the async method names with Async, which also is in line with naming conventions.

MongoDb is a good case study of a major framework implementing an async API. When they release 2.0 they only provided async methods, but recently they re-added sync methods to their API. They have a huge community, and I guess they had some long discussions before they decided on this. That, and the fact that it's nice to be backward compatible are two reasons for keeping the existing api.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Feb 10, 2016

Contributor

Guys, should I send in a larger PR with my proposal or do you want to set the baselines first?

Contributor

danielmarbach commented Feb 10, 2016

Guys, should I send in a larger PR with my proposal or do you want to set the baselines first?

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Feb 10, 2016

Member

@danielmarbach we wouldn't mind if you decided to expand your proposal. We also don't want you to waste a lot of time on it, though, as we still haven't had a chance to take a look and announce the changes coming to .NET client this year.

Member

michaelklishin commented Feb 10, 2016

@danielmarbach we wouldn't mind if you decided to expand your proposal. We also don't want you to waste a lot of time on it, though, as we still haven't had a chance to take a look and announce the changes coming to .NET client this year.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Feb 23, 2016

Member

We've recently reviewed #151 and #149. I will post some notes and an overview of our plan later this week.

Member

michaelklishin commented Feb 23, 2016

We've recently reviewed #151 and #149. I will post some notes and an overview of our plan later this week.

@SimonCropp

This comment has been minimized.

Show comment
Hide comment
@SimonCropp

SimonCropp commented May 5, 2016

@michaelklishin any update?

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin May 5, 2016

Member

@SimonCropp the only update I have is that we have someone with a lot of .NET experience on our team now and that person will be working on a new client built around async/await. No ETA, no promises.

Member

michaelklishin commented May 5, 2016

@SimonCropp the only update I have is that we have someone with a lot of .NET experience on our team now and that person will be working on a new client built around async/await. No ETA, no promises.

@SimonCropp

This comment has been minimized.

Show comment
Hide comment

SimonCropp commented May 5, 2016

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach May 5, 2016

Contributor

Just to restate: I offered my help as well.

Am 05.05.2016 um 10:38 schrieb Michael Klishin notifications@github.com:

@SimonCropp the only update I have is that we have someone with a lot of .NET experience on our team now and that person will be working on a new client built around async/await. No ETA, no promises.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Contributor

danielmarbach commented May 5, 2016

Just to restate: I offered my help as well.

Am 05.05.2016 um 10:38 schrieb Michael Klishin notifications@github.com:

@SimonCropp the only update I have is that we have someone with a lot of .NET experience on our team now and that person will be working on a new client built around async/await. No ETA, no promises.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin May 5, 2016

Member

We've outlined our plan for the future of this client on rabbitmq-users.

Member

michaelklishin commented May 5, 2016

We've outlined our plan for the future of this client on rabbitmq-users.

@PeterKottas

This comment has been minimized.

Show comment
Hide comment
@PeterKottas

PeterKottas Jul 19, 2016

Hello all, very nice to see effort in this direction. Do you have any news on availability of async client? Latest comments are from end of May as far as I know and I was wondering if you have a clearer picture by now. This https://github.com/clearctvm/RabbitMqNext for sure looks great but I would sleep better if we can have it backed up by the community behind rabbit.

PeterKottas commented Jul 19, 2016

Hello all, very nice to see effort in this direction. Do you have any news on availability of async client? Latest comments are from end of May as far as I know and I was wondering if you have a clearer picture by now. This https://github.com/clearctvm/RabbitMqNext for sure looks great but I would sleep better if we can have it backed up by the community behind rabbit.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jul 19, 2016

Member

@PeterKottas no updates. We've focussed on #148 in June and likely won't start working on the new client until September or so. It will take months to develop anyway.

Member

michaelklishin commented Jul 19, 2016

@PeterKottas no updates. We've focussed on #148 in June and likely won't start working on the new client until September or so. It will take months to develop anyway.

@PeterKottas

This comment has been minimized.

Show comment
Hide comment
@PeterKottas

PeterKottas Jul 20, 2016

Thanks for the info @michaelklishin , I'll check back around the end of the year then.

PeterKottas commented Jul 20, 2016

Thanks for the info @michaelklishin , I'll check back around the end of the year then.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jul 20, 2016

Member

@PeterKottas I'd check back in Q1-Q2 2017.

Member

michaelklishin commented Jul 20, 2016

@PeterKottas I'd check back in Q1-Q2 2017.

@asbjornu

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Oct 21, 2016

@michaelklishin Just my two cents: @PeterKottas' referenced RabbitMqNext looks like a very decent starting point for an officially supported async capable client. Please consider forking it in some way when this initiative is bootstrapped next year.

Another alternative is https://github.com/EasyNetQ/EasyNetQ, which also has async support.

asbjornu commented Oct 21, 2016

@michaelklishin Just my two cents: @PeterKottas' referenced RabbitMqNext looks like a very decent starting point for an officially supported async capable client. Please consider forking it in some way when this initiative is bootstrapped next year.

Another alternative is https://github.com/EasyNetQ/EasyNetQ, which also has async support.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Oct 21, 2016

Member

@asbjornu thank you for the input. Our plan is to develop a client from scratch. That said, we are happy to heavily borrow from existing projects. EasyNetQ is quite different in scope from a "regular" RabbitMQ client, though.

Member

michaelklishin commented Oct 21, 2016

@asbjornu thank you for the input. Our plan is to develop a client from scratch. That said, we are happy to heavily borrow from existing projects. EasyNetQ is quite different in scope from a "regular" RabbitMQ client, though.

@kjnilsson

This comment has been minimized.

Show comment
Hide comment
@kjnilsson

kjnilsson Oct 21, 2016

Contributor

EasyNetQ is a convenience/conventions wrapper over the current .NET client but there may be aspects of the surface API that we could learn from.
RabbitMqNext does have some nice features and implementation details that are well worth considering.
Ultimately it will be a matter of first solidifying what is wanted/needed from a new client and then decide how to best realize that. Async is only one of the aspects (albeit a significant one). We also may need to consider (amongst others):

  • How intuitive the API is to new users.
  • How the API works with other languages on .NET (powershell / fsharp).
  • How easily it can be maintained.
  • How can it be debugged/introspected.
  • How easy it's threading and failure semantics are to reason about.
Contributor

kjnilsson commented Oct 21, 2016

EasyNetQ is a convenience/conventions wrapper over the current .NET client but there may be aspects of the surface API that we could learn from.
RabbitMqNext does have some nice features and implementation details that are well worth considering.
Ultimately it will be a matter of first solidifying what is wanted/needed from a new client and then decide how to best realize that. Async is only one of the aspects (albeit a significant one). We also may need to consider (amongst others):

  • How intuitive the API is to new users.
  • How the API works with other languages on .NET (powershell / fsharp).
  • How easily it can be maintained.
  • How can it be debugged/introspected.
  • How easy it's threading and failure semantics are to reason about.
@asbjornu

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Oct 27, 2016

@michaelklishin: Thanks for the info. I agree with @kjnilsson's list of concerns. It would be awesome if the client provided both a low-level API as well as a higher level abstraction such as EasyNetQ. To be honest, the current official client leaves a lot to be desired in terms of user friendliness.

If one's not a die-hard expert on how RabbitMQ works, it's very hard to set it up "right" (where "right" matches 80% of the most common usage patterns) the first time. Properties such as ConnectionFactory.AutomaticRecoveryEnabled not being set to true by default, for instance, has been a common cause of problems in our organization. I would expect these sorts of "sensible defaults" would be set in the higher level abstraction, leaving the lower level to those who are RabbitMQ experts and want to perform tweaks and customizations as close to the metal as possible.

I'm really looking forward to how and where this ends up. 😃

asbjornu commented Oct 27, 2016

@michaelklishin: Thanks for the info. I agree with @kjnilsson's list of concerns. It would be awesome if the client provided both a low-level API as well as a higher level abstraction such as EasyNetQ. To be honest, the current official client leaves a lot to be desired in terms of user friendliness.

If one's not a die-hard expert on how RabbitMQ works, it's very hard to set it up "right" (where "right" matches 80% of the most common usage patterns) the first time. Properties such as ConnectionFactory.AutomaticRecoveryEnabled not being set to true by default, for instance, has been a common cause of problems in our organization. I would expect these sorts of "sensible defaults" would be set in the higher level abstraction, leaving the lower level to those who are RabbitMQ experts and want to perform tweaks and customizations as close to the metal as possible.

I'm really looking forward to how and where this ends up. 😃

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Oct 27, 2016

Member

Automatic recovery was introduced less than 2 years ago. Now that we know that it works well in practice (and what kind of issues there were in the Java client, which is a couple of steps ahead of this client in some areas) perhaps it can be enabled by default in a future version. That doesn't have to wait for the new client, though.

Member

michaelklishin commented Oct 27, 2016

Automatic recovery was introduced less than 2 years ago. Now that we know that it works well in practice (and what kind of issues there were in the Java client, which is a couple of steps ahead of this client in some areas) perhaps it can be enabled by default in a future version. That doesn't have to wait for the new client, though.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Oct 27, 2016

Contributor

I hope the higher level abstraction will be a dedicated package and not coupled together with the low level driver in one package

Am 27.10.2016 um 21:19 schrieb Asbjørn Ulsberg notifications@github.com:

@michaelklishin: Thanks for the info. I agree with @kjnilsson's list of concerns. It would be awesome if the client provided both a low-level API as well as a higher level abstraction such as EasyNetQ. To be honest, the current official client leaves a lot to be desired in terms of user friendliness.

If one's not a die-hard expert on how RabbitMQ works, it's very hard to set it up "right" (where "right" matches 80% of the most common usage patterns) the first time. Properties such as ConnectionFactory.AutomaticRecoveryEnabled not being set to true by default, for instance, has been a common cause of problems in our organization. I would expect these sorts of "sensible defaults" would be set in the higher level abstraction, leaving the lower level to those who are RabbitMQ experts and want to perform tweaks and customizations as close to the metal as possible.

I'm really looking forward to how and where this ends up. 😃


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Contributor

danielmarbach commented Oct 27, 2016

I hope the higher level abstraction will be a dedicated package and not coupled together with the low level driver in one package

Am 27.10.2016 um 21:19 schrieb Asbjørn Ulsberg notifications@github.com:

@michaelklishin: Thanks for the info. I agree with @kjnilsson's list of concerns. It would be awesome if the client provided both a low-level API as well as a higher level abstraction such as EasyNetQ. To be honest, the current official client leaves a lot to be desired in terms of user friendliness.

If one's not a die-hard expert on how RabbitMQ works, it's very hard to set it up "right" (where "right" matches 80% of the most common usage patterns) the first time. Properties such as ConnectionFactory.AutomaticRecoveryEnabled not being set to true by default, for instance, has been a common cause of problems in our organization. I would expect these sorts of "sensible defaults" would be set in the higher level abstraction, leaving the lower level to those who are RabbitMQ experts and want to perform tweaks and customizations as close to the metal as possible.

I'm really looking forward to how and where this ends up. 😃


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Oct 27, 2016

Member

It's unlikely that we will include any abstractions meaningfully higher
level than what the current client has. Existing
projects such as EasyNetQ, NServiceBus and so on fill this niche pretty
well already.

On Fri, Oct 28, 2016 at 12:05 AM, Daniel Marbach notifications@github.com
wrote:

I hope the higher level abstraction will be a dedicated package and not
coupled together with the low level driver in one package

Am 27.10.2016 um 21:19 schrieb Asbjørn Ulsberg <notifications@github.com
:

@michaelklishin: Thanks for the info. I agree with @kjnilsson's list of
concerns. It would be awesome if the client provided both a low-level API
as well as a higher level abstraction such as EasyNetQ. To be honest, the
current official client leaves a lot to be desired in terms of user
friendliness.

If one's not a die-hard expert on how RabbitMQ works, it's very hard to
set it up "right" (where "right" matches 80% of the most common usage
patterns) the first time. Properties such as ConnectionFactory.AutomaticRecoveryEnabled
not being set to true by default, for instance, has been a common cause of
problems in our organization. I would expect these sorts of "sensible
defaults" would be set in the higher level abstraction, leaving the lower
level to those who are RabbitMQ experts and want to perform tweaks and
customizations as close to the metal as possible.

I'm really looking forward to how and where this ends up. 😃


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAEQiNiMLuonPDxM1_9_GSzRudZYcmTks5q4RIIgaJpZM4EOu3x
.

MK

Staff Software Engineer, Pivotal/RabbitMQ

Member

michaelklishin commented Oct 27, 2016

It's unlikely that we will include any abstractions meaningfully higher
level than what the current client has. Existing
projects such as EasyNetQ, NServiceBus and so on fill this niche pretty
well already.

On Fri, Oct 28, 2016 at 12:05 AM, Daniel Marbach notifications@github.com
wrote:

I hope the higher level abstraction will be a dedicated package and not
coupled together with the low level driver in one package

Am 27.10.2016 um 21:19 schrieb Asbjørn Ulsberg <notifications@github.com
:

@michaelklishin: Thanks for the info. I agree with @kjnilsson's list of
concerns. It would be awesome if the client provided both a low-level API
as well as a higher level abstraction such as EasyNetQ. To be honest, the
current official client leaves a lot to be desired in terms of user
friendliness.

If one's not a die-hard expert on how RabbitMQ works, it's very hard to
set it up "right" (where "right" matches 80% of the most common usage
patterns) the first time. Properties such as ConnectionFactory.AutomaticRecoveryEnabled
not being set to true by default, for instance, has been a common cause of
problems in our organization. I would expect these sorts of "sensible
defaults" would be set in the higher level abstraction, leaving the lower
level to those who are RabbitMQ experts and want to perform tweaks and
customizations as close to the metal as possible.

I'm really looking forward to how and where this ends up. 😃


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAEQiNiMLuonPDxM1_9_GSzRudZYcmTks5q4RIIgaJpZM4EOu3x
.

MK

Staff Software Engineer, Pivotal/RabbitMQ

@lasseschou

This comment has been minimized.

Show comment
Hide comment
@lasseschou

lasseschou Nov 3, 2016

@kjnilsson Just a shout-out from a user looking forward to the TPL-based client. Quick question: Is the progress of the new client available here on GitHub? If so, can you share a link to the repo? Thanks!

lasseschou commented Nov 3, 2016

@kjnilsson Just a shout-out from a user looking forward to the TPL-based client. Quick question: Is the progress of the new client available here on GitHub? If so, can you share a link to the repo? Thanks!

@lasseschou

This comment has been minimized.

Show comment
Hide comment
@lasseschou

lasseschou commented Nov 3, 2016

I meant @michaelklishin - sorry :)

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Nov 3, 2016

Member

The work on the new client begins next year.

On 3 Nov 2016, at 07:51, lasseschou notifications@github.com wrote:

I meant @michaelklishin - sorry :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Member

michaelklishin commented Nov 3, 2016

The work on the new client begins next year.

On 3 Nov 2016, at 07:51, lasseschou notifications@github.com wrote:

I meant @michaelklishin - sorry :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach Feb 4, 2017

Contributor

I sent in a PR which would enable opt-in async consumer dispatch in a non-breaking way that can be delivered as a minor, see #307 as soon as I get green light I'll make it a bit more efficient

Contributor

danielmarbach commented Feb 4, 2017

I sent in a PR which would enable opt-in async consumer dispatch in a non-breaking way that can be delivered as a minor, see #307 as soon as I get green light I'll make it a bit more efficient

@gabrieligbastos

This comment has been minimized.

Show comment
Hide comment

gabrieligbastos commented Feb 10, 2017

+1

@ujeenator

This comment has been minimized.

Show comment
Hide comment
@ujeenator

ujeenator commented Feb 24, 2017

+1

@michaelklishin michaelklishin removed their assignment Feb 24, 2017

@VladimirMakaev

This comment has been minimized.

Show comment
Hide comment

VladimirMakaev commented Mar 15, 2017

+1

@rabbitmq rabbitmq locked and limited conversation to collaborators Mar 15, 2017

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Mar 15, 2017

Member

I'm locking this because it's been decided that we will develop a new async/await-oriented client from scratch. Isolated improvements such as #307 are still possible but no major API revisions are going to happen in this client.

Sorry but we don't need any more +1s.

Member

michaelklishin commented Mar 15, 2017

I'm locking this because it's been decided that we will develop a new async/await-oriented client from scratch. Isolated improvements such as #307 are still possible but no major API revisions are going to happen in this client.

Sorry but we don't need any more +1s.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.