The MemberAssignment bytes returned in SyncResponse should be the bytes that your leader sent in its SyncRequest. <<0, 0, 0, 0>> is simply an empty Bytes array (32 bit length of 0). The broker does not alter those bytes as far as I know, so despite the protocol doc describing what a MemberAssignment struct *should* look like, it really is up to your client to encode and decode that struct. Can you check what bytes your leader code is sending?
I assume you have this covered, but for completeness: each consumer should check its JoinResponse to determine whether it has been selected as the group leader. If the consumer is the leader, it needs to do the assignments and send those back in its SyncRequest. All other consumers just send an empty SyncRequest. SyncResponse for all consumers then includes the assignments sent by the leader. -Dana On Sat, Mar 26, 2016 at 2:39 PM, Cees de Groot <c...@pagerduty.com> wrote: > I'm helping out on adding 0.9 stuff to the Elixir Kafka driver ( > https://github.com/kafkaex/kafka_ex), and I'm getting an unexpected > response on an integration test that makes a simple SyncGroup call. > > In Elixir terms, I'm getting <<0, 0, 0, 3, 0, 0, 0, 0, 0, 0>> back. My > interpretation: > > 32 bits correlation id = 0,0,0,3 > 16 bits error code = 0,0 > > There's now 32 bits left. However, I'm expecting (following > > https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-SyncGroupResponse > ) > a MemberAssignment structure here, which is > > 16 bits of version (0) > 32 bits of length (it's a simple integration test, so for now i'm happy to > accept the answer "0 assignments for you, dude!" ;-)). > > Which clearly is more data than left in the response. > > Am I misinterpreting the documentation here? >
