ProduceAsync Locking Up

[Coder3333]

Description

When I call await ProduceAsync, it locks up indefinitely. I only wait for 1 minute. This sounds a lot like #545, but I am using the 1.0.0 Confluent NuGet.

I only see this when I run from my unit tests, which is xUnit on .Net Core 2.1. When I run the same code from a web application, it never locks up. Also, this does not happen 100% of the time. If I have a test that publishes 3 times synchronously, it could lock up on any one of the 3, or none at all. Oddly, it seems to happen less often when I run the test in Debug mode with VS, as opposed to when I run without debugging.

I am not getting any logs or errors from the producer during this lock up period.

How to reproduce

Call await ProduceAsync from an xUnit test in .Net Core.

[mhowlett]

My guess is tests are running concurrently and you're using a SyncrhonizationContext with a small number of threads. This could easily deadlock. You could try using .ConfigureAwait(false) to not enforce that tasks be completed on the same synchronization context. I don't know too much about xUnit, but the following link is consistent with the above theory: https://stackoverflow.com/questions/50918647/why-does-this-xunit-test-deadlock-on-a-single-cpu-vm

[Coder3333]

I thought the xunit deadlock solution sounded good, but I tried it and it has not had any affect.

I have written a ton of async framework code and I have never heard of ConfigureAwait until I started researching this ProduceAsync problem. The times I have seen async deadlock, it was happening 100% of the time, like from a WPF application. I have never seen it like this where it seems to happen only 25% of the time.

I tried adding ConfigureAwait in a few places, but I think it will be tough to get them all. It did not help when I just added it in a few spots.

[mhowlett]

a WPF SynchronizationContext is single threaded, guaranteeing a deadlock.

[levdimov]

We have the same issue after upgrading to 1.0.0 from 0.11.4: Confluent.Kafka.Producer async code doesn't have any ConfigureAwait(false) statements (ex:

confluent-kafka-dotnet/src/Confluent.Kafka/Producer.cs

Line 679 in 91d71ec

return await handler.Task;

). Before 1.0.0 Producer code was returning tasks rather than awaiting them inside implementation.

Sure, the main problem was that we synchronously waited for task to complete (using GetAwaiter().GetResult()) in IIS app, but isn't it safer for everyone to use ConfigureAwait(false) anywhere in a library code? Is there any reason not to configure Tasks?

@mhowlett, it would be great if we have a talk about this issue.

[mhowlett]

whoops, it looks like i forgot to include them. thanks for working through this. closing in favor of #967,