Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.30.1 patched #1

Closed
wants to merge 3 commits into from
Closed

v1.30.1 patched #1

wants to merge 3 commits into from

Conversation

niamster
Copy link

Compared to v1.30.1:

IBM#2111
IBM#2108

- support decoding V0 and V1 "ConsumerProtocolSubscription" types in the
  DescribeGroupsResponse member metadata (i.e., the new "OwnedPartition"
  values that may be included by a KIP-429 consumer)
- add workaround for the legacy bsm/sarama-cluster client which
  incorrectly set V1 in its JoinGroup request, but doesn't include the
  new V1+ fields!
  https://github.com/bsm/sarama-cluster/blob/d5779253526cc8a3129a0e5d7cc429f4b4473ab4/consumer.go#L644-L648
- also guard GetMemberAssignment and GetMemberMetadata from panic'ing
  when the fields are empty, which they will be in certain scenarios
  such as non-stable groups or clients without any assigned
  topicpartitions
After Sarama had been given a preferred replica to consume from, it was
mistakenly latching onto that value and not unsetting it in the case
that the preferred replica broker was shutdown and left the cluster
metadata.

Fetches continued to work as long as that broker remained shutdown,
because they were now being sent to the Leader, which would service them
itself as it had no better preferred replica to point the client at.

However, consumption would then hang after the broker came back online,
because the Leader would stop returning records in the FetchResponse and
would instead just return the preferred replicaID, expecting the
client to send its FetchRequests over there. However, because the
partitionConsumer had latched the value of preferredReplica it never
dispatched to (re-)connect to the preferred replica and instead just
continued to send FetchRequests to the leader and received no records
back.

Contributes-to: IBM#2090

Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
@niamster niamster closed this Apr 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants