[Feature Request] Please make sync APIs available again, do not force consumers and producers to block on async

[iancooper]

Is your feature request related to a problem? Please describe.

async/await is not SDK "magic faerie dust". Whilst it is important to support it, it is also important to support sync APIs.

If you do not support synchronous APIs you impose a design decision on all consumers of your SDK: you must use asynchronous i/o or you have to block on an asynchronous operation. The problem here is that blocking on an asynchronous operation is far worse of a problem, than using blocking i/o.

An async/await programming model is viral; it forces the whole program, from top-to-bottom to become async. This may or may not be a valid choice, but as an SDK owner, you cannot determine this

In addition, in some cases, blocking i/o may be a better option, so you should leave this open for clients.

I note that the ASP.NET team had to roll back their decision to provide only non-blocking APIs, for exactly the same problem space.

Generally, SDK writers should not make choices for their users, as they cannot know their context. Specifically, they should not choose their concurrency model in this case. You can be opinionated, and prefer some options over others, but always provide an escape route to allow your opinions to be avoided.

You don't have the context to decide if a consumer should use async/await.

Describe the solution you'd like

A #dotnet SDK should support both blocking and non-blocking operations, so as to not force design decisions on consumers of that SDK, or force dangerous behaviors such as blocking on async.

Please put the synchronous APIs back into the SDK, with immediate effect.

Describe alternatives you've considered

One alternative here is to fork the SDK, and to put synchronous approaches back into the SDK. This seems to be an unhelpful response, so it would be better to discuss why this SDK change should be reconsidered.

Additional context

It is great that there are now asynchronous APIs. But the support for asynchronous APIs should not come at the expense of imposing design decisions on consumers of your SDK.

[Tornhoof]

I note that the ASP.NET team had to roll back their decision to provide only non-blocking APIs, for exactly the same problem space.

Just curious, which one do you mean, AllowSynchronousIO for HttpResponse et al?

Or do you mean the Sync Api for HttpClient in Runtime, which was heavily influenced by Azure SDK support back in the day.
The HttpClient change only implements a limited set of sync functionality, for Http/1.1 there is a full sync path afaik, Http2/3 are only sync over async.

On Bluesky you wrote that for Message Consumers you have valid sync use cases, what are these?
I'd understand Message Publishing for legacy code bases, as async is viral.

But why the consumers? They should be fairly easily adapted as you just need some kind of backgroundservice doing the async startup.

[iancooper]

I note that the ASP.NET team had to roll back their decision to provide only non-blocking APIs, for exactly the same problem space.

Just curious, which one do you mean, AllowSynchronousIO for HttpResponse et al?

You may be interested to follow this thread: The ASP.NET team was forced to begin rolling back their change from .NET 5, and more so in .NET 6.

Generally speaking, it is a bad idea to impose this decision on your users, because you cannot know their context. You do not know, as a library author, whether they should use async i/o or not. Some reasons that they might choose to be sync:

• Legacy concerns: this is not just that their code is legacy, but that they have legacy dependencies that themselves do not support async i/o. They will be forced to block in the async pipeline. Never a good choice. The viral nature of async/await means that you need to provide an escape hatch
• Simpler progamming model: in some cases they may not need the throughput offered by async i/o. Remember, the operation still awaits, so it does not perform better, it simply yields, allowing higher throughput. They may not have the throughput concerns that force them to use async, and may prefer a synchronous programming model
• They may want to use blocking operations to provide backpressure

These are just some of the problems. The simple answer is that as a library designer, you cannot know.

[iancooper]

But why the consumers? They should be fairly easily adapted as you just need some kind of backgroundservice doing the async startup.

But you have now made an assumption about the range of possible ways that I can write my code.

async i/o is not "magic faerie dust". For example, local file i/o is generally faster via a blocking method than a non-blocking method, particularly as the CLR does not have truly asynchonous file i/o. A read-write to an SSD is faster via a blocking call than an async one.

Do you know all your user's contexts? Do you know all their paradigms under which they will use their code?

[iancooper]

As a framework author which uses RabbitMQ as one of our transports, and supports both sync and async for our users, because we don't want to assume their context, we would have to block over async to use this, or adopt a strategy of

var task = Task.Run(() => //rmq operation; task.Wait(); var response = task.Result;

around every RMQ call via an extension method wrapper for safety, to allow folks to continue to have a choice about their concurrency context.

[Tornhoof]

You may be interested to follow

Yeah that's the HttpClient change I was referring to, which was heavily influenced by Azure (as written in the first post and commented a lot in that thread) and specifically that the support is only partial.

But you have now made an assumption about the range of possible ways that I can write my code.

No I'm not making assumptions. I understand that you want to provide the users of your framework a sync api.
As for SSDs, I think by now io_uring is largely comparable if not faster than epoll for NVMEs.
See e.g. https://lore.kernel.org/io-uring/ZwW7_cRr_UpbEC-X@LQ3V64L9R2/T/ for a recent round of benchmarks

I'm just curious why you think message consumers being an interesting use case for sync, if I correctly understand your code in BrighterCommand's RMQ PullConsumer you already push all received messages into a ConcurrentQueue.
If that use case is the interesting one, then you my suggestion above still applies.

But I also think that the async code in the current iteration of the RabbitMQ library is far superior than the previous code, both in readability/maintainability and performance metrics, as it uses a lot of the more modern functionality provided by the dotnet team in recent years.

Note: I don't have any skin in the game here, I just tried to provide you help to solve the problem of your sync consumer.
Having said that, I leave the further discussion up to the maintainers.

[iancooper]

This seems to have been the problematic change: #1472

[iancooper]

I'm just curious why you think message consumers being an interesting use case for sync

It may be worth reading David's comments here: https://bsky.app/profile/keansbox.com/post/3lc3lop3ewc2w

Async is a choice, and I make it when I want to choose co-operation over performance. In some cases, I may not want to choose co-operation. Software scales just fine without yielding to other threads all the time. For example, if I run a single-threaded worker in a container, I may well not choose to yield by using await; I may just rely on co-operative multi-tasking, because I want to optimise performance, reduce allocations etc.

The reality here is this: the RabbitMQ SDK CANNOT know my context. So dropping support for sync is a strong opinion about the types of RabbitMQ consumers you are prepared to support. The answer here from Broadcom is: if you have legacy needs, if you want performance over co-operation, if you want a simpler programming model: we don't care, please use something other than RabbitMQ for your workloads.

[michaelklishin]

There is very little specifics in this "request", so it belongs to a discussion.

async/await is not SDK "magic faerie dust".
Whilst it is important to support it, it is also important to support sync APIs.

We never claim anywhere that it is "magic fairy dust". A large percentage of active contributors have been asking for an "async first" interface for years. Now that we finally have it, apparently it's not good enough.

The RabbitMQ core team is tiny, and we have the API that most contributors want. If you want an alternative, you are welcome to contribute it.

A #dotnet SDK should support both blocking and non-blocking operations, so as to not force design
decisions on consumers of that SDK, or force dangerous behaviors such as blocking on async

Is there a law of physics that states that ".NET SDKs" should or should not do this or that? I think it's a perfectly fine choice for a library that implements an inherently asynchronous messaging protocol to have an asynchronous interface.

Having "sync alternatives" for a few key channel methods likely won't see much opposition as long as

1. The async interface does not degrade
2. Some sync interface lovers step up to contribute it, at least a few specific examples and tests, and not just a brief textual explanation of how sync interfaces are important. This is open source software, not "free labor on the Internet"

[michaelklishin]

@iancooper are you willing to contribute such a "sync API" for at least connection, channel.open, channel.close, queue.declare, basic.publish and basic.consume methods, to demonstrate the idea or serve as a base for others to join?

If you are not then I'm afraid our team does not have the resources to support two implementations of the protocol. I mean, we have just spent a few years moving to async because since 2015 or so, it has been the most requested feature, second to none.

[iancooper]

in inherently asynchronous messaging protocol to have an asynchronous interface

Oh gosh, these are entirely different meanings of asynchronous. One is an asynchronous conversation, where both parties do not need to be present at the same time. The other is yielding your thread to await a call back via polling a completion port. They are not even close as ideas, and one does not indicate the other.

[iancooper]

are you willing to contribute such a "sync API"

I guess the question would be how much the "fields have been sown with salt" and therefore it is to get back to a sync API. I will take a look. I know there was a PR, where you stripped out the sync API. It is possible that is a starting point, depending on why you stripped it at that point (problems with the way you were providing a sync API over the internals).

A first step may be to wrap the async api calls, in as safe an approach as possible, because many clients will be forced into that; at least if it is done safely, although with a performance cost, in the a sync version of the api will be in a less bad place that we are now. From there I suspect we could look at fixing this, so that we don't force a concurrency model on the consumer.

it has been the most requested feature, second to none
But I presume the request was to add an asynchronous model, not to remove any synchronous API. What I wonder about is the advice you had from anyone to completely remove sync support as part of that. That seems like bad advice, from folks who don't understand async/await vs. sync trade-offs

[iancooper]

Yeah, I think that the advice that you received here was problematic, as it seems to have only reached a very narrow audience, who were focused on delivering the async API, not on the needs of actual consumers.

[iancooper]

So, I think the first step is figuring out how to revert this change, and move forward from there.

[michaelklishin]

Yeah, I think that the advice that you received https://github.com/rabbitmq/rabbitmq-dotnet-
client/discussions/1471 was problematic, as it seems to have only reached a very narrow audience,
who were focused on delivering the async API, not on the needs of actual consumers.

So apparently you know better than the maintainers. This is an unbelievable level of arrogance.

[michaelklishin]

@iancooper I will not take any more of this "I know better than the maintainers". We (the RabbitMQ Core Team) talk to the users of this library virtually every day, whether we like it or not.

No one has objected to the async API that was under development for about three years or so. And now that the train is gone and you've missed it, you expect us to do a U-turn.

I find it difficult to believe that there can be something meaningful contributed with this kind of disregard for what key contributors have spent several years on, all working in this repo in the open.
So I won't even bother suggesting contributing a PR.

[michaelklishin]

It's not every day that you run into a situation where a major revisit to an API of a popular library is in the works for about three years in the open, then the changes are finished and shipped, with many preview releases along the route, and then a non-contributor with very strong opinions shows up.

But this is also not unheard of. Keeping a sync API in 7.x makes a certain amount of sense to allow for easier (and by that I do not promise "almost effortless" or "drop-in") upgrades to a version that has plenty of important internal improvements that also have been requested and worked on for a long time.

So, Where Do We Go from Here?

So the only productive option I see is to ask every major contributor to 7.0 to consider reverting #1472 for 7.1.0 and see how can the maintenance of the sync API be minimized.

However, if the key maintainer and regular contributors do not agree to maintain the previous sync API on top of the new one, this debate will be settled once an for all, and those who really want a sync API would have to build it in a wrapper library (which no one prevents them from doing even today).

Previous Discussions

I also could find some indications that the key maintainer of this library, @lukebakken, had plenty of doubts about how a sync API can be supported and whether that would even be realistic, for example, in #1471.

In #1471 (comment), Luke suggests that someone should contribute an implementation of one of those ideas and there were no takers. Which is fine, but demonstrates the level of interest amongst those who regularly contribute and participate in discussions. Which is not a good sign for the future of the sync API, if there's any, even as part of the 7.x series only, not permanently.

[michaelklishin]

I have asked a group of regular or less-regular-but-long-time contributors in #1738, all while making sure we won't have a repetition of the above conversation.

[lukebakken]

@iancooper the 6.x series is available for people who wish to continue using the old API. That version of the library has warts and could use some contributions from the community to fix them. Search issues and discussions for "ThreadPool", for instance.

We welcome useful contributions to this project.