Andreas Heider

If you want throughput then try to have many produce messages in flight simultaneously instead of awaiting them individually. For example with `Task.WaitAll` or by using `.ContinueWith` instead of `await`....

Thanks for all the debugging, this was really helpful! I think this is fixed now in https://github.com/ah-/rdkafka-dotnet/commit/a0c53430a018753ef69c535ec5d126bbfc497bc3, by cancelling the polling task in the finalizer, which should guarantee it doesn't...

You're right about the issue, it's certainly real and has most likely to do with cleanup order. I think it's because there's no guaranteed order in which the finalizers run....

This sounds like a librdkafka issue, could you report it at https://github.com/edenhill/librdkafka/issues?

Do you have any detail on what exactly is wrong?

Probably @edenhill can help you more. I'm not entirely sure what's going on there, could you run this with a bit more debug logging? I wonder if anything happens between...

There's now a 0.9.2 build up. Could you check if you can still reproduce it with that?

A couple of things you could look at: Is there anything suspicious in the broker/zookeeper logs? Turn on config["debug"] = "cgrp", does this say anything interesting? Maybe the consumer group...

It goes to stdout by default, you can override that via https://github.com/ah-/rdkafka-dotnet/blob/master/src/RdKafka/Config.cs#L66

There's a couple of connection issues in that log: ``` Connect to ipv4#10.152.165.45:9092 failed FAIL| 10.152.165.233:9092/177776105: 3 request(s) timed out: disconnect Connect to ipv4#10.152.168.196:9092 failed ``` How many brokers do...