Dominic Evans

The suggested changes were merged into Sarama. Closing this issue as resolved

Closing as duplicate of #1441 — feel free to re-open if that's not the case

Closing as presumed to have been resolved. Please reopen if not

We believe this issue is fixed in recent versions of Sarama. Feel free to re-open if you're still seeing a problem on the latest

I agree that the goroutine lifecycle management in Sarama could do with an overhaul. As you highlight here, these async close goroutines shouldn't really be fire-and-forget and the parent Close...

@J-Orange-Sun sorry for the slow response to your issue, did you resolve this one?

@longit644 the consumer should attempt to re-join the group automatically if it is evicted @go-slark did you ever resolve your problem? Is this still an issue for you?

@joshua0x Sarama has `MaxProcessingTime` as a config parameter similar to the Java client's `max.poll.interval.ms` https://github.com/IBM/sarama/blob/d2dba29e9545c5af80169e541b1170c3dd34b3b9/config.go#L391-L408 It is a locally enforced client timeout and is separate from the heartbeat to the...

That’s not the case. Sarama will shuffle those bootstrap addresses on request. It will cycle through them to gain connectivity and then uses the advertised listeners for each broker when...

FetchResponse >= v3 is basically anything newer than Kafka 0.10.1, which is basically everything these days, so we probably don't need to version guard any change here. However, it's not...