Open canni opened 7 months ago
Hi @canni thx for filing: quick question -> are you running Confluent Kafka or another environment? We have a PR ready for Confluent Kafka support where we tried to make sure to avoid races when closing. Need to look closer into the sarama implementation or do you want to file a PR?
@yanmxa FYI, that's why I was so picky during the PR review :)
Yes this is when we connect to cluster using confluent docker containers
Would you be open to switch and try our upcoming kafka_confluent
binding?
I don't know if we can find time to get around to testing that before Easter break, I'll report after the trial run
No worries, #988 merge still pending (though close). Then we need to cut a new release so you can easily switch. Appreciate the support.
@canni https://github.com/cloudevents/sdk-go/pull/988 is merged
We're experiencing a panic due to send on a closed channel here: https://github.com/cloudevents/sdk-go/blob/release-v2.15.2/protocol/kafka_sarama/v2/receiver.go#L80
I've traced this to the fact that the
incoming
channel is closed in SDK managed goroutine here: https://github.com/cloudevents/sdk-go/blob/release-v2.15.2/protocol/kafka_sarama/v2/receiver.go#L182But the
ConsumeClaim
is running in sarama's internal goroutine, and it's session context is unrelated. This creates situaction where closing the receiver prematurely closes the incoming channel used byConsumeClaim
This panic is crashing the whole go process, as wrapping
StartReceiver
withrecover()
does not cover that goroutine.