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

Cannot specify JoinGroupRequest protocol priority #812

Closed
DanielMorsing opened this issue Jan 24, 2017 · 3 comments
Closed

Cannot specify JoinGroupRequest protocol priority #812

DanielMorsing opened this issue Jan 24, 2017 · 3 comments
Assignees
Labels

Comments

@DanielMorsing
Copy link

DanielMorsing commented Jan 24, 2017

Versions

Present on every version that supports JoinGroupRequest

Problem Description

The kafka protocol for JoinGroupRequest allows you to specify priority on group protocols for seamless rollout of new protocols while a consumer group is running. This is done by changing the ordering on the wire for the GroupProtocols. See here for more details

Sarama exposes this field as a map, making it impossible to specify an ordering.

@eapache
Copy link
Contributor

eapache commented Jan 25, 2017

Note that the join group request allows for multiple protocol/metadata pairs. This enables rolling upgrades without downtime. The coordinator chooses a single protocol which all members support.

This is what is in the wiki; I don't read that as implying that order is important. The coordinator should only choose a protocol once all of the group members support it, regardless of order?

@DanielMorsing
Copy link
Author

Later in the wiki:

Once all members have upgraded, the coordinator will choose whichever protocol is listed first in the GroupProtocols array.

If you're switching from "protov1" to "protov2", you want to deploy your binaries such that they can handle both in the switchover, but once every consumer has been updated, you want to ensure that "protov2" is chosen. The protocol ordering allows for doing this.

@eapache eapache added bug and removed question labels Jan 25, 2017
@eapache
Copy link
Contributor

eapache commented Jan 25, 2017

Oh yes you're right I'm sorry I must have missed that the first read through.

Fixing this without breaking API compatibility will be a bit awkward but should be possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants