Contributors: your thoughts on restoring the sync API for 7.x?

[michaelklishin]

Background

This is a question specifically for those who regularly contribute to this client or at least participate in discussions (which is also a form of contribution):

@lukebakken @stebet @bording @danielmarbach @bollhals @paulomorgado @kjnilsson @Gsantomaggio

It is a follow-up to #1737 where some very strong opinions were expressed by a person who has never contributed to this client. The author of that issue won't participate in this discussion due to interaction limits for 30 days, as I don't think we need to hear how "us maintainers are all dummies, this non-contributor knows better know what Joe and Jill the regular users need" one more time 😮‍💨

The Decision We are Seeking to Make

Should we revert #1472 for 7.x specifically.

I am not even trying to ask about a possibility to forward port such an API to 8.x and future versions. If we cannot agree to support a sync API even in 7.x, the idea of longer term support is DOA.

Earlier Considerations

This is not the first time this topic was brought up amongst the maintainers. Some earlier discussions:

1. Version 7 API - issue with mixing sync / async in same API #1471
2. 7.0 release checklist / misc items #1413
3. Reduce public API as much as possible #714

[michaelklishin]

I am no longer a regular contributor to this client but I do maintain and contribute to a good dozen of RabbitMQ client libraries, and see how they are used and abused virtually every day. So I guess my opinion can be approximated to that of a contributor, or at least a former contributor with a lot of relevant experience elsewhere.

Most clients only support one API, be it sync or async. Mind you, the async model and syntactic sugar do not exist in every programming language but a few others (JS, Python) have adopted something very similar. There's also the .NET client for the RabbitMQ Stream Protocol that we can take a look at.

In those languages, usually it's either "all async" or "all sync".

Python

Some examples in Python:

0. https://github.com/pika/pika, the oldest client still in development today, supports different I/O adapters and a "hybrid" API, and Team RabbitMQ knows that the combination is not always easy to maintain. @lukebakken has spent a lot of time on Pika
1. https://github.com/mosquito/aio-pika?tab=readme-ov-file#features is all async by design
2. https://github.com/polyconseil/aioamqp is all async seemingly by design
3. https://github.com/airtai/faststream (not RabbitMQ-specific, targets RabbitMQ Stream Protocol and not AMQP 0-9-1) is all async
4. https://gitlab.com/wrobell/rbfly is seemingly all async, or at least async is the primary interface advertised
5. https://github.com/qweeze/rstream is all async

So async-only libraries for Python are the norm, even if Pika, which is used in RabbitMQ tutorials, is an exception or not an "async-only" client.

JavaScript, TypeScript

Moving on to JavaScript:

1. https://github.com/amqp-node/amqplib offers both a callback and a Promise/Future-based API. This is an older client than some others, that pre-dates the async syntactic sugar in modern JS
2. https://github.com/cloudamqp/amqp-client.js is all async
3. https://github.com/coders51/rabbitmq-stream-js-client is a RabbitMQ Stream Protocol client, all async
4. https://github.com/cody-greene/node-rabbitmq-client is an all-async AMQP 0-9-1 client

So in the JavaScript world we see the same situation: older clients offer two different APIs, async is usually offered at least in terms of a Promise-based API, and all newer libraries are all async.

Rust

In Rust, mixing async and sync code is fairly complicated. Quite a few libraries prefer an async interface, while providing some helpers for when there are reasons to not use async. The maintenance
burden of this is non-trivial. Some clients effectively have two reasonably different versions in one,
and that has obvious support load ramifications. I maintain one of such libraries.

Java

In Java, there is a couple of client libraries but the absolutely dominant one is the one we have. It offers a sync-ish API and two options for I/O: regular synchronous one and NIO (async I/O). NIO has been a hotly requested feature for years and a non-trivial percentage of direct users have adopted it, as far as I can tell.

Hop, the HTTP API Java client, supports both a sync and async APIs but it is a library much smaller in scope and changes only when something is added to the HTTP API. In other words, it is easy to maintain the two versions because it does not take a lot of maintenance in general, and that is not the case for the .NET AMQP 0-9-1 client.

.NET Stream Client

.NET client for the RabbitMQ Stream Protocol only offers an async API and I haven't see any complaints about that.

When Did Async API Discussions Start?

About eight years ago, with #307 being the first specific API change, a new IBasicConsumer implementation.

The biggest discussion of that era was #83,
where there already were observations of clients moving to async is the base of their API and
sometimes having a sync option on top.

Over time, however, the requests started being heavily skewed towards "when will the async API ship?" and not about how to support the sync API. That work has intensified in 2020 and in several stages we have arrived to the peak of activity in 2023-2024 that's culminated in 7.0.0.

What I am getting from this issue/discussion archeology is that the expectations of this client have gradually moved to an async API and the sync API has mostly disappeared from the discussions up until fall 2024 when it has become a time-pressing decision to make.

And most discussions after 7.0.0 that I recall were about how to adopt 7.0.0 and the new API, not about how the sync API can be preserved, up until #1737.

Will RabbitMQ .NET Client 6.x Be Compatible with RabbitMQ 4.x?

Let's have a look at whether using .NET client 6.x with its sync API would be a feasible alternatives for those who won't be able to make the switch in 2024-2025.

RabbitMQ's implementation of AMQP 0-9-1 changes rarely, and usually with additions of small protocol extensions for specific problems, such as update.secret to accommodate OAuth 2 JWT token refresh.

RabbitMQ .NET client 2.0 can still connect to RabbitMQ 4.x, and .NET client 7.x can still connect to RabbitMQ 2.0+ all the way to 4.0.

In other words, there's a chance that .NET client 6.x users will be able to adopt future RabbitMQ 4.x and, say, 5.x releases with no or very few changes, all while using the same good ole sync API.

Now, whether there will be any support offered for 6.x down the road, I don't know, but the client
will very likely be perfectly useable with future RabbitMQ releases. Or at least the ≈ 18 year old history of this client suggests that is the baseline scenario.

So What is Your Vote?

I don't have a strong opinion.

If the sync client will prove to be difficult to maintain alongside the async one, I vote against restoring the sync API.

If the sync client can be maintained with a small amount of effort and without holding back the new async API, keeping it in 7.x for now makes sense to me to simplify upgrades.

Based on earlier discussions, this is a big if.

[michaelklishin]

I have also asked a couple of RabbitMQ client library contributors to take a look. I cannot know if they'd like to comment on a .NET client specifically, let's see.

[michaelklishin]

Now there is a speculation on a certain .NET community member social media account that claims that some of the contributors mentioned above have "pressured" our team to decide one way or another. I've been a RabbitMQ contributor since 2010 one way or another, and a contributor this client since 2013 (not so much recently but still).

During this time period, some of the folks above have been contributing regularly since at least 2015. They have developed trust and good will with this team, and it's the most natural thing in an open source project that those who contribute regularly get to influence the direction of the project, and those who do not even participate in discussions have no influence.

So with that out of the way, let's see what are the contributing folk willing to do about the 6.x API. It can be re-introduced, or 6.x can be maintained for another year or so (including shipping new minors if necessary), or a new façade library can be built on top of the 7.x API as a separate library.

Step one is deciding if there's any interest in maintaining the 6.x API of sorts for the longer term, or the 6.x series. Speaking of which, the 6.x series will enjoy a period of maintenance in any case, and can be used with RabbitMQ 4.0, future 4.1, and most likely a reasonable number of releases down the road simply because protocol-level changes are incredibly rare. I recall two limited ones in the ≈ 18 year old history of this library.

[paulomorgado]

There are some strong opinions/comments in there, so I will allow myself some.

A single synchronous blocking operation is usually more performant than an asynchronous one. Asynchronous operations are about availability and scalability and not single operation performance.

I'm simply not having a discussion about .NET/C# with someone that writes code like var task = Task.Run(() => //rmq operation; task.Wait(); var response = task.Result; in November 2024.

But this is not about a single comment and about all users.

I haven't yet delved into the changes needed to adapt my code to version 7, so I don't have first hand experience.

But, since 6.x is supported and can be used, and synchronous APIs have to mostly be reimplemented, I'd measure first before drawing a conclusion.

What are the downloads of 7.x versus 6.x?
What specific complaints users have against the asynchronous APIs?
What use cases prove to be measurably better synchronous than asynchronous?

[michaelklishin]

We cannot compare the number of downloads, they are all automated these days. 6.x is years old, and the sync API is 18 years old, vs. a couple of months of GA availability of 7.0. Of course the number right now will be drastically different, and so they will in a year.

So far we have seen one complaint about the fact that the sync API is gone entirely, and several discussions on how to best migrate certain examples to 7.x. I do not recall a single complaint about the tutorials that use 7.0, and they have been updated almost immediately after 7.0.0 shipped.

[paulomorgado]

When I referred to downloads, I meant the trend, If 7.x increase doesn't surpass 6.x, means users are sticking with 6.x.

[lukebakken]

If users wish to continue using the old API, they are more than welcome to use and contribute to the 6.x series of this library. Issues around the use of the ThreadPool should be fixed, and hopefully people like @iancooper can step up and help out.

If we get enough feedback, especially from businesses with commercial RabbitMQ licenses, that indicates this topic should be re-visited, we can do so for version 8.

[Gsantomaggio]

Agree with @lukebakken

[danielmarbach]

Thanks for inviting me to this conversation.

I’d like to emphasize that these are my opinions and not those of my employer. For me, contributing to the RabbitMQ client has always been more of a hobby or side project. I enjoy the community and the opportunity to tackle real-world challenges I can help solve. Of course, this is only possible because I have the context from the problem domain I interact with during my day job, as well as the privilege of a job that pays the bills—allowing me the luxury of treating evening coding as an enjoyable hobby.

Taking a step back and reviewing the previous discussion linked in this thread, I wonder if we may have ventured too quickly into somewhat emotional territory. I can’t speak for everyone involved, but knowing both Ian and Michael for a long time (albeit mostly asynchronously—pun intended), I believe all parties are genuinely trying to find the best way forward. It seems that some aspects of the conversation may have gotten “lost in translation.”

For example, from various discussions with @iancooper, I’ve learned that he genuinely embodies the spirit of open source. He strives to collaborate and support both his community and the broader one here. I’m fairly certain that his comments in the other thread were made with good intentions. Given Ian’s extensive experience with various messaging solutions across platforms, I think it would be valuable to give him the benefit of the doubt and re-engage him in this conversation. We all have the opportunity to learn from one another here.

I’ll follow up with some subject-specific input a bit later. I look forward to continuing this discussion with all of you.

[danielmarbach]

@michaelklishin , have you been able to give this some thought? Especially the part of unblocking Ian. I would really love to benefit from Ian's breadth and depth of experience in this topic (and framework/library in general) to get a good grasp of the topic.

Knowing Ian personally, I'm also certain he has considered his role in the previous conversation and is happy to own that part.

[lukebakken]

Especially the part of unblocking Ian

I did that yesterday 😸

[lukebakken]

Although, right now, there's not much to add to my comment.

For the foreseeable future, if someone needs to use the sync API, they should use the 6.x versions of this library. PRs to fix issues in that branch are very welcome, will be reviewed, and merged, with new releases to follow.

[danielmarbach]

Now that I’ve made the other comment, here are my thoughts on the discussion and some of the points raised throughout the conversation, which are spread across multiple issues and discussions.

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 block on an asynchronous operation. The problem here is that blocking on an asynchronous operation is far worse than using blocking I/O.

This is an absolutely correct observation from @iancooper. Using Task.Result or Task.Wait to block while waiting for an asynchronous operation to complete is FAR worse than calling a truly synchronous API to block. This phenomenon, known as "sync over async," works as follows at a high level:

1. An asynchronous operation is initiated.
2. The calling thread is blocked, waiting for the operation to complete.
3. When the asynchronous operation finishes, it unblocks the waiting code—on another thread.

The result is that two threads are used instead of one to complete synchronous operations. This often leads to thread pool starvation, potentially causing service outages.

An async/await programming model is viral; it forces the whole program, from top to bottom, to become async.

This is also true. Introducing an async API deep in the call stack requires making the entire call chain asynchronous up to the entry point. These restrictions may be due to factors beyond the owning team's control. For widely used methods, the "virality" of async can cause ripple effects throughout the codebase, complicating containment of changes. While guidelines and resources (including my talk—shameless plug!) can help address these challenges, valid business or monetary reasons might justify not adopting async.

My question is: when such valid decisions are made, how much interest remains in switching to a modern library version beyond addressing security vulnerabilities?

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

This is a controversial topic, with arguments on both sides. Putting aside memory considerations for a moment, the Orleans: Distributed Virtual Actors for Programmability and Scalability paper was enlightening for me a few years ago.

The paper discusses how Orleans uses asynchronous I/O and cooperative multitasking to mask latency in distributed actor calls (Section 5.1). Switching RPC calls to asynchronous in .NET achieves similar benefits, as shown in Orleans benchmarks. With synchronous RPC, each call blocks a thread, tying up resources during I/O-bound operations like network calls or database queries. In contrast, asynchronous RPC frees threads to handle other tasks while waiting, improving overall throughput.

Section 3.4 of the Orleans paper highlights how asynchronous operations prevent application code from holding a thread during I/O, maximizing throughput in distributed systems. Similarly, .NET’s async/await model excels at handling I/O-bound workloads, enabling systems to serve more concurrent requests with minimal latency impact.

The benchmarks in Section 5.1 demonstrate how asynchronous I/O and cooperative multitasking mask latency in actor calls. These principles directly apply to asynchronous RPC in .NET, leading to better resource utilization and higher throughput.

However, as David Kean noted in a linked discussion, synchronous I/O can sometimes be better—particularly when the underlying I/O system "fakes" I/O completion ports by offloading continuations to the worker thread pool. Yet, this seems like a small corner case taken out of context. See also: Synchronous I/O Anti-Pattern.

Let’s also not forget that the underlying thread pool and async state machines are continuously improved, making some edge cases less relevant over time.

Generally, SDK writers should not make choices for their users, as they cannot know their context. Specifically, they should not choose their concurrency model. You can be opinionated and prefer certain options, but always provide an escape route.

This is an interesting argument. It suggests that SDK authors shouldn’t make decisions on behalf of users, such as dropping support for older frameworks. However, just as users may have valid reasons to stay on an older platform, SDK maintainers can have valid reasons to cease supporting certain parts of an SDK when the cost-benefit ratio no longer makes sense.

This is perhaps the crux of the discussion: some in the community favor progress, sometimes at the expense of having to let go something else, while others advocate for maintaining "legacy" support. The community favoring progress might dominate the conversation here, creating an echo chamber that overlooks alternative contexts. Discussions like this are valuable, provided the RabbitMQ maintainer team’s perspective is also considered.

From my understanding, the .NET client has one official maintainer, with the rest being community-driven. This dynamic may further contribute to the echo chamber effect I’ve mentioned before.

In my opinion, properly supporting both API styles ("colors") means duplicating effort in some areas, such as maintaining and fixing bugs in two paths because two "cores" are required. This increases the SDK’s maintenance overhead and diverts resources from potential improvements. Ultimately, it’s about making trade-offs based on available resources.

There are also "less puristic" but "convenient" approaches, such as providing a sync-over-async wrapper like RavenDB’s AsyncHelper:

• DocumentStore.cs
• AsyncHelpers.cs

These wrappers simplify usage but may still hide thread pool starvation issues, requiring users to tweak thread pool limits to avoid problems.

That being said, I'm not against re-introducing the synchronous variants when all those things have been considered

[danielmarbach]

After reviewing Brighter, I want to clarify that my intent here is not to criticize the team’s decisions but to highlight what I perceive as a logical flaw in the argumentation. Specifically, I assume Ian's input represents the user base behind Brighter.

Looking at Brighter's current code, I observed several occurrences of .Wait(), .GetAwaiter().GetResult(), and Thread.Sleep across various components, including messaging gateways for AWS SQS, Azure Service Bus, MQTT, and others. For example:

• .Wait() is used in infrastructure setup and messaging paths, including in AzureServiceBusConsumer and SqsMessageConsumer.
• .GetAwaiter().GetResult() appears frequently, especially in SQS and Azure Service Bus integrations.
• Thread.Sleep is also present, notably in SQS and Azure Service Bus code.

While some of these calls occur during setup or infrastructure interactions, others exist on the "hot path" in messaging gateways. This indicates that Brighter provides both synchronous and asynchronous APIs, likely for user convenience. However, this approach has consequences, such as "sync-over-async" patterns when integrated SDKs don’t offer synchronous APIs. This is particularly evident in the Azure Service Bus and SQS integrations.

Given these design tradeoffs and the resulting thread starvation challenges (e.g., the need for guidance on adjusting thread pool limits), I'm struggling to understand how RabbitMQ's move to async-only APIs could be seen as making things worse. Is the concern that async-only APIs inherently cause issues? Or is the argument broader, suggesting that the SDKs for Azure Service Bus and SQS are also "flawed"?

Targets
    Occurrences of '.Wait()' in All Places
Found usages  (31 usages found)
    <Paramore.Brighter.Extensions.Hosting>  (1 usage found)
        <Paramore.Brighter.Extensions.Hosting>\TimedOutboxSweeper.cs  (1 usage found)
            132 _distributedLock.ReleaseLockAsync(LockingResourceName, lockId, CancellationToken.None).Wait();
    <Paramore.Brighter.MessagingGateway.AWSSQS>  (8 usages found)
        <Paramore.Brighter.MessagingGateway.AWSSQS>\ChannelFactory.cs  (2 usages found)
            84 EnsureTopicAsync(_subscription.RoutingKey, _subscription.SnsAttributes, _subscription.FindTopicBy, _subscription.MakeChannels).Wait();
            376 sqsClient.DeleteQueueAsync(queueExists.name).Wait();
        <Paramore.Brighter.MessagingGateway.AWSSQS>\SqsMessageConsumer.cs  (5 usages found)
            152 client.DeleteMessageAsync(new DeleteMessageRequest(urlResponse.QueueUrl, receiptHandle)).Wait();
            186 client.ChangeMessageVisibilityAsync(new ChangeMessageVisibilityRequest(urlResponse.QueueUrl, receiptHandle, 0)).Wait();
            190 client.DeleteMessageAsync(urlResponse.QueueUrl, receiptHandle).Wait();
            211 client.PurgeQueueAsync(urlResponse.QueueUrl).Wait();
            244 client.ChangeMessageVisibilityAsync(new ChangeMessageVisibilityRequest(urlResponse.QueueUrl, receiptHandle, delay.Value.Seconds)).Wait();
        <Paramore.Brighter.MessagingGateway.AWSSQS>\SqsMessageProducer.cs  (1 usage found)
            113 SendAsync(message).Wait();
    <Paramore.Brighter.MessagingGateway.AzureServiceBus>  (4 usages found)
        AzureServiceBusWrappers  (1 usage found)
            AdministrationClientWrapper.cs  (1 usage found)
                234 CreateSubscriptionAsync(topicName, subscriptionName, subscriptionConfiguration).Wait();
        <Paramore.Brighter.MessagingGateway.AzureServiceBus>\AzureServiceBusConsumer.cs  (2 usages found)
            148 ServiceBusReceiver?.Complete(lockToken).Wait();
            191 ServiceBusReceiver?.DeadLetter(lockToken).Wait();
        <Paramore.Brighter.MessagingGateway.AzureServiceBus>\AzureServiceBusMessageProducer.cs  (1 usage found)
            157 SendWithDelayAsync(message, delay).Wait();
    <Paramore.Brighter.MessagingGateway.MQTT>  (1 usage found)
        <Paramore.Brighter.MessagingGateway.MQTT>\MQTTMessageConsumer.cs  (1 usage found)
            65 connectTask.Wait();
    <Paramore.Brighter.MessagingGateway.MsSql>  (2 usages found)
        SqlQueues  (1 usage found)
            MsSqlMessageQueue.cs  (1 usage found)
                105 Task.Delay(RetryDelay).Wait();
        <Paramore.Brighter.MessagingGateway.MsSql>\MsSqlMessageConsumer.cs  (1 usage found)
            90 Task.Delay(delay.Value).Wait();
    <Paramore.Brighter.MessagingGateway.RMQ>  (4 usages found)
        <Paramore.Brighter.MessagingGateway.RMQ>\PullConsumer.cs  (1 usage found)
            77 Task.Delay(pause).Wait();
        <Paramore.Brighter.MessagingGateway.RMQ>\RmqMessageConsumer.cs  (1 usage found)
            213 if (timeout > TimeSpan.Zero) Task.Delay(timeout.Value).Wait();
        <Paramore.Brighter.MessagingGateway.RMQ>\RmqMessageGatewayConnectionPool.cs  (1 usage found)
            154 Task.Delay(jitter.Next(5, 100)).Wait();
        <Paramore.Brighter.MessagingGateway.RMQ>\RmqMessageProducer.cs  (1 usage found)
            141 Task.Delay(delay.Value).Wait();
    <Paramore.Brighter.MessagingGateway.Redis>  (1 usage found)
        <Paramore.Brighter.MessagingGateway.Redis>\RedisMessageConsumer.cs  (1 usage found)
            172 Task.Delay(delay.Value).Wait();
    <Paramore.Brighter.MsSql.Azure>  (1 usage found)
        <Paramore.Brighter.MsSql.Azure>\MsSqlAzureConnectionProviderBase.cs  (1 usage found)
            58 _semaphoreToken.Wait();
    <Paramore.Brighter.ServiceActivator>  (5 usages found)
        Ports  (1 usage found)
            Handlers  (1 usage found)
                ConfigurationCommandHandler.cs  (1 usage found)
                    65 _dispatcher.End().Wait();
        <Paramore.Brighter.ServiceActivator>\Dispatcher.cs  (1 usage found)
            374 Task.Delay(100).Wait();
        <Paramore.Brighter.ServiceActivator>\MessagePump.cs  (3 usages found)
            155 Task.Delay(ChannelFailureDelay).Wait();
            163 Task.Delay(ChannelFailureDelay).Wait();
            186 Task.Delay(EmptyChannelDelay).Wait();
    <Paramore.Brighter>  (4 usages found)
        <Paramore.Brighter>\OutboxProducerMediator.cs  (4 usages found)
            277 s_clearSemaphoreToken.Wait();
            568 s_backgroundClearSemaphoreToken.Wait();
            569 s_clearSemaphoreToken.Wait();
            1048 s_checkOutstandingSemaphoreToken.Wait();

and

Targets
    Occurrences of '.GetAwaiter().GetResult()' in All Places
Found usages  (35 usages found)
    <Paramore.Brighter.DynamoDb>  (1 usage found)
        <Paramore.Brighter.DynamoDb>\DynamoDbUnitOfWork.cs  (1 usage found)
            43 LastResponse = DynamoDb.TransactWriteItemsAsync(_tx).GetAwaiter().GetResult();
    <Paramore.Brighter.MessagingGateway.AWSSQS>  (14 usages found)
        <Paramore.Brighter.MessagingGateway.AWSSQS>\ChannelFactory.cs  (9 usages found)
            172 var response = sqsClient.CreateQueueAsync(request).GetAwaiter().GetResult();
            220 var createDeadLetterQueueResponse = sqsClient.CreateQueueAsync(request).GetAwaiter().GetResult();
            232 var attributesResponse = sqsClient.GetQueueAttributesAsync(attributesRequest).GetAwaiter().GetResult();
            356 response = snsClient.ListSubscriptionsByTopicAsync(new ListSubscriptionsByTopicRequest {TopicArn = ChannelTopicArn}).GetAwaiter().GetResult();
            392 (bool exists, string topicArn) = new ValidateTopicByArn(snsClient).ValidateAsync(ChannelTopicArn).GetAwaiter().GetResult();
            411 snsClient.DeleteTopicAsync(ChannelTopicArn).GetAwaiter().GetResult();
            419 ).GetAwaiter().GetResult();
            434 response = snsClient.ListSubscriptionsByTopicAsync(new ListSubscriptionsByTopicRequest {TopicArn = ChannelTopicArn}).GetAwaiter().GetResult();
            437 var unsubscribe = snsClient.UnsubscribeAsync(new UnsubscribeRequest {SubscriptionArn = sub.SubscriptionArn}).GetAwaiter().GetResult();
        <Paramore.Brighter.MessagingGateway.AWSSQS>\SnsMessageProducerFactory.cs  (1 usage found)
            53 if (producer.ConfirmTopicExistsAsync().GetAwaiter().GetResult())
        <Paramore.Brighter.MessagingGateway.AWSSQS>\SqsMessageConsumer.cs  (3 usages found)
            83 var urlResponse = client.GetQueueUrlAsync(_queueName).GetAwaiter().GetResult();
            96 var receiveResponse = client.ReceiveMessageAsync(request).GetAwaiter().GetResult();
            261 var topic = snsClient.FindTopicAsync(topicName.Value).GetAwaiter().GetResult();
        <Paramore.Brighter.MessagingGateway.AWSSQS>\ValidateTopicByArnConvention.cs  (1 usage found)
            59 .GetAwaiter().GetResult();
    <Paramore.Brighter.MessagingGateway.AzureServiceBus>  (8 usages found)
        AzureServiceBusWrappers  (7 usages found)
            AdministrationClientWrapper.cs  (4 usages found)
                52 result = _administrationClient.TopicExistsAsync(topicName).GetAwaiter().GetResult();
                85 result = _administrationClient.QueueExistsAsync(queueName).GetAwaiter().GetResult();
                120 }).GetAwaiter().GetResult();
                145 }).GetAwaiter().GetResult();
            ServiceBusReceiverProvider.cs  (2 usages found)
                28 new ServiceBusSessionReceiverOptions() {ReceiveMode = ServiceBusReceiveMode.PeekLock}).GetAwaiter().GetResult());
                62 new ServiceBusSessionReceiverOptions() {ReceiveMode = ServiceBusReceiveMode.PeekLock}).GetAwaiter().GetResult());
            ServiceBusReceiverWrapper.cs  (1 usage found)
                35 _messageReceiver.CloseAsync().GetAwaiter().GetResult();
        <Paramore.Brighter.MessagingGateway.AzureServiceBus>\AzureServiceBusConsumer.cs  (1 usage found)
            71 .GetAwaiter().GetResult();
    <Paramore.Brighter.MessagingGateway.Kafka>  (1 usage found)
        <Paramore.Brighter.MessagingGateway.Kafka>\KafkaMessagingGateway.cs  (1 usage found)
            64 MakeTopic().GetAwaiter().GetResult();
    <Paramore.Brighter.MessagingGateway.MQTT>  (2 usages found)
        <Paramore.Brighter.MessagingGateway.MQTT>\MQTTMessagePublisher.cs  (2 usages found)
            58 _mqttClient.ConnectAsync(_mqttClientOptions, CancellationToken.None).GetAwaiter().GetResult();
            75 PublishMessageAsync(message).GetAwaiter().GetResult();
    <Paramore.Brighter.MsSql.Azure>  (5 usages found)
        <Paramore.Brighter.MsSql.Azure>\MsSqlChainedConnectionProvider.cs  (1 usage found)
            32 return GetAccessTokenFromProviderAsync(CancellationToken.None).GetAwaiter().GetResult();
        <Paramore.Brighter.MsSql.Azure>\MsSqlDefaultAzureConnectionProvider.cs  (1 usage found)
            18 return GetAccessTokenFromProviderAsync(CancellationToken.None).GetAwaiter().GetResult();
        <Paramore.Brighter.MsSql.Azure>\MsSqlManagedIdentityConnectionProvider.cs  (1 usage found)
            20 return GetAccessTokenFromProviderAsync(CancellationToken.None).GetAwaiter().GetResult();
        <Paramore.Brighter.MsSql.Azure>\MsSqlSharedTokenCacheConnectionProvider.cs  (1 usage found)
            39 return GetAccessTokenFromProviderAsync(CancellationToken.None).GetAwaiter().GetResult();
        <Paramore.Brighter.MsSql.Azure>\MsSqlVisualStudioConnectionProvider.cs  (1 usage found)
            20 return GetAccessTokenFromProviderAsync(CancellationToken.None).GetAwaiter().GetResult();
    <Paramore.Brighter.Outbox.DynamoDB>  (3 usages found)
        <Paramore.Brighter.Outbox.DynamoDB>\DynamoDbOutbox.cs  (3 usages found)
            132 AddAsync(message, requestContext, outBoxTimeout).ConfigureAwait(ContinueOnCapturedContext).GetAwaiter().GetResult();
            216 DeleteAsync(messageIds, requestContext).GetAwaiter().GetResult();
            257 .GetAwaiter().GetResult();
    <Paramore.Brighter.ServiceActivator>  (1 usage found)
        <Paramore.Brighter.ServiceActivator>\MessagePumpAsync.cs  (1 usage found)
            162 return future.GetAwaiter().GetResult();

and

Targets
    Occurrences of 'Thread.Sleep' in Solution
Found usages  (3 usages found)
    <Paramore.Brighter.MessagingGateway.AWSSQS>  (2 usages found)
        <Paramore.Brighter.MessagingGateway.AWSSQS>\ChannelFactory.cs  (2 usages found)
            193 Thread.Sleep(TimeSpan.FromSeconds(30));
            251 Thread.Sleep(TimeSpan.FromSeconds(30));
    <Paramore.Brighter.MessagingGateway.AzureServiceBus>  (1 usage found)
        <Paramore.Brighter.MessagingGateway.AzureServiceBus>\AzureServiceBusMessageProducer.cs  (1 usage found)
            223 Thread.Sleep(TimeSpan.FromMilliseconds(TopicConnectionSleepBetweenRetriesInMilliseconds));

[iancooper]

We would be very happy to take the feedback via an issue raised within Brighter, if you wanted to do that. We could then discuss them there with the team. Just in case, we are aware of these, and there are issues for a number of them. Many are items on our V10 work list. Not all of our contributors can recognize the issue, so we often get contributions for transports where usage of GetAwaiter().GetResult() is how those problems get resolved. In some cases, such as setup, we may not worry about this because the additional thread is unlikely to cause a problem, but in other places we do. You can see notes to that effect on the recent PR about RMQ V7.

But this our very concern about what happens when we don't have sync APIs available. And yes, the problem exists for us across the differences between clients that will support async, and those that don't. For example, in the Kafka dotnet client the async versions of the API tend to be avoided because they have low throughput. But this causes problems such as use of sync over async when using Kafka's built in serializers.

Yes, my concern would applies to other APIs too. There are different routes for feedback for some of those, and we talk about the issue in those contexts.

It is an overall ecosystem problem.

[danielmarbach]

We would be very happy to take the feedback via an issue raised within Brighter, if you wanted to do tha

Feel free to quote me in appropriate contexts.

[iancooper]

Damn, I thought I might get a contribution out of you ;-)

[iancooper]

Specifically, I assume Ian's input represents the user base behind Brighter.

Not my intent. I was simply highlighting that for many folks this is hard. For folks using Brighter, likely to be easier, as we will do the work to handle it for them.

[Zerpet]

Michael asked me to share my thoughts on this topic. I have contributed here and there to this library, but I have far less knowledge of the codebase than many here.

I'm generally on the side that favours progress, over maintaining "legacy" for decades. This doesn't mean maintainers get a free card to make breaking changes all around. When I was asked about removing the sync part of this library, I was in favour, and I still think it was a good decision, because Luke found many challenges to keep both APIs available, and we had many signals, from trusted sources, to move the API to async (as Michael pointed out regarding trusted contributors). My opinion is that "legacy" should not hinder progress and natural evolution. A company or a person can have valid reasons to not modernise some of their code. It is their decision to stay behind, with the consequences that comes with such decision.

Generally, SDK writers should not make choices for their users, as they cannot know their context. Specifically, they should not choose their concurrency model. You can be opinionated and prefer certain options, but always provide an escape route.

I don't agree to this opinion. When SDK authors give you a toolkit, you are expected to use the toolkit in a certain way, with some restrictions, assumptions and opinions that come with the SDK. You can argue about the restrictions and opinions, but you can't have an "opinion-free" SDK. This effectively means that an SDK will make some choices for you, with the intent of helping you solve a problem. If you don't like those choices, or opinions, then simply don't use the SDK.

I vote for keeping 6.x major for sync API, and I vote against adding back sync API in main or 7.x major.

[michaelklishin]

Ultimately, it’s about making trade-offs based on available resources

Correct. It's not that (at least most) maintainers "despise" the 6.x API. We simply don't want to stretch ourselves too thin maintaining both.

But as long as there are 6.x users who are willing to meaningfully contribute (to this generally very mature library), 6.x can be kept afloat (or even meaningfully improved within the limits of minor and patch releases).

[MarcialRosales]

I vote for keeping the sync API going forward. I do not think that using async is the right way in all cases however if our API is going to force users to use async it means that they have to, literally, "work around". Typically creating a wrapper that converts the async-api to a sync one. Of course, as owners of the api, we can decide what is best for the users while keeping the code maintainable. But here, I am not so sure it is justifiable to drop the sync-api.

[iancooper]

Thanks for allowing me to comment.

Can I first take this opportunity to apologize to you all for any upset my words caused you. I will try to choose my words more carefully. I would like to re-iterate my comment in the issue that I am grateful for all the hard work on V7, to produce an async version. It will be enormously helpful.

I have nothing but respect for the work of the people here, some of whom I know, and I am mortified that my comments were ill-thought out, and upset you.

[lukebakken]

Thanks. On a daily basis Team RabbitMQ receives messages from users who have never meaningfully contributed to any free software project, much less RabbitMQ, demanding features, support, changes, etc ("Please put the synchronous APIs back into the SDK, with immediate effect."), and it gets old very quickly. You probably run into the same issue with your "BrighterCommand" project.

Really, what Team RabbitMQ wants are:

• Useful bug reports from users who use the latest version of RabbitMQ.
• Pull requests to implement features, fix bugs, etc.
• Paid support contracts, in which case much more latitude is given, of course.

Anything else is likely to be met with the same sort of response given to #1737.

[iancooper]

Moving on from this comment, I recognize the comments by @lukebakken about the constraints he is under as the only developer, and therefore his need to control the scope of the work. Pragmatically, that does mean the solution is for the community to self-service the sync API provided by V6 for now.

Thanks for listening to my request thoughtfully in this thread though. I can certainly try to give some of my free time to that end.

[iancooper]

I did want to clarify one point about my use of the word SDK and why it is that I perceive that there a difference between an SDK and a framework.

With a framework, you are offering reusable code to solve a common problem. It may well have strong opinions. That is great because it is likely that we will have a lot of frameworks, representing different developers opinions, and you get to choose ones that suit you. In the dotnet space, if you don't like my opinions on Brighter, you can instead go and choose the opinions of Mass Transit, Wolverine or NServiceBus. That is good, and a healthy ecosystem should have lots of fine opinions for you to choose from. There is an easy escape route. You can sidestep frameworks you don't like altogether and have no framework if you desire; which is another kind of escape route and the problem is in many parts greater effort over more difficult.

For me, an SDK does more than this, it abstracts a particular protocol for your chosen development language. If I can't use your SDK, for whatever reason, my escape route is to use the protocol directly. Now, if my SDK abstracts an HTTP+JSON API, a lot of developers will have the skills to escape the SDK, and write their own. Perhaps they can even share it. But once I get into a protocol like amqp 0-9-1 the number of developers who can escape the official SDK and write their own is going to be far fewer. The contributors to this repo might be a lot of the folks who can do that for the dotnet community. And that means there are possibly no escape routes for folks.