lack of async code / sync over async

[JanEggers]

Im having some deadlocks in my Unittests during shutdown. it is certainly related to #874.
Im not using a sync task completion source but something else that leads to the test executing in the context of receiving a message.

I know that it would be a big impact breaking change but are there any considerations to make more operations async?

there seem to be some async code paths in the implementation but as long as they use sync over async they are prone to cause deadlocks / use more resources (threads) than actually needed...

https://github.com/rabbitmq/rabbitmq-dotnet-client/search?q=getawaiter%28%29.getresult

I really like the project bedrock stuff @davidfowl came up with but the rabbitmq bits in there are early prototype / id rather like to use the official package..

https://github.com/davidfowl/BedrockFramework/tree/master/src/Bedrock.Framework.Experimental/Protocols/RabbitMQ

[michaelklishin]

See #83. This client has over a decade of history and making it entirely async is not going to work, although to some extent this has been done (e.g. there's an async consumer operation dispatcher). We have concluded that an "everything async" client should be a separate library.

[asbjornu]

@michaelklishin, I got the clear impression from #869 that 7.0 is going to be full async. What am I misunderstanding?

[sungam3r]

I got the clear impression from #869 that 7.0 is going to be full async. What am I misunderstanding?

I asked the same question.

[JanEggers]

@asbjornu thx for pointing me to that pr looks promising

[michaelklishin]

The comments in #869 make it pretty clear that there are many open-ended questions and we don't want to change the API of the client entirely as very few would upgrade.

[JanEggers]

@michaelklishin in #869 you are talking about a call. Did that happpen / what was the conclusion?

We have concluded that an "everything async" client should be a separate library.

is this the conclusion? If so is this project started already? Can I start it?

@stebet are you going to rebase #706 any time soon? I would be willing to help if that is ok for you.

[stebet]

There is a lot of stuff that could be reused between the sync/async libraries (most of the (de)serialization among other things). Let's see if I can take some of the async work I've made and start something this week. I'll keep y'all in the loop for feedback/ideas :)

Sound good?

[asbjornu]

The comments in #869 make it pretty clear that there are many open-ended questions

@michaelklishin, true. But the pull request is both merged and assigned to the milestone 7.0.0, giving the impression that not only is async incoming, it will arrive in version 7 of RabbitMQ.Client.

and we don't want to change the API of the client entirely as very few would upgrade.

I beg to differ. As a consumer of RabbitMQ.Client I'm bothered by the lack of full async on an almost daily basis and would love to change it out with a new official one supporting async, even though it would mean rewriting all of my RabbitMQ-interfacing code (which isn't much anyway; most of the important stuff happens both before and after de/serialization, which means it is going to be completely reusable).

There is a lot of stuff that could be reused between the sync/async libraries (most of the (de)serialization among other things). Let's see if I can take some of the async work I've made and start something this week. I'll keep y'all in the loop for feedback/ideas :)

That sounds great, @stebet! 👍