Makes sense. Thanks!
(and now how to find out how to turn off that signature for mailing lists
;-))
On Sun, Mar 27, 2016 at 10:54 AM, Dana Powers wrote:
> Agree, it's a bit confusing based on wiki alone right now. I think of
> MemberAssignment as a double-serialized field: first serialize to by
Agree, it's a bit confusing based on wiki alone right now. I think of
MemberAssignment as a double-serialized field: first serialize to bytes
using the MemberAssignment definition (version, topics, partitions, etc);
then serialize the bytes into a request. It's the second serialization step
that ad
Ah. That makes sense. That also means that on the outgoing request, this
part should be coded as ? These parts of
the documentation aren't entirely clear on what is part of the
client/server protocol and what is part of the (client-side only) consumer
group implementation.
I'll put my request and
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
MemberAssignmen
