> I don't want to be a hater of idempotent HB, but having a "RPC" used to
generate UUID is unnecessary to me.

I actually agree with you. I am just trying to argue for it.

> I'm not sure whether it is worth requiring the UUID format for member id.
In the protocol, we declare the field "memberId" as "String" rather than
"uuid". The scope of member id is in "a group", so I guess the collision
won't be a big issue.

I think that this should be defined. Otherwise, folks may start using
incorrect things. In the java client, we will generate a Kafka UUID.
The javadoc of the Uuid class has a good definition for it.

> For another, I always wonder why we trust clients to generate "unique"
transaction id but we worry about generating "unique" member id on client
side?

This is perhaps not the best comparison. The transactional id is the most
misused thing in Apache Kafka. However, there is a notable difference. The
transaction id is provided by the end user where the member id is generated
by the client itself.


On Wed, Aug 14, 2024 at 11:56 AM Chia-Ping Tsai <chia7...@gmail.com> wrote:

> In my opinion, the main downside of this
> approach is that if you leave after receiving the first HB and the member
> id, the server will respond with an unknown member id error because the
> member is not really in the group yet.
>
> I don't want to be a hater of idempotent HB, but having a "RPC" used to
> generate UUID is unnecessary to me.
>
> In the proposed changes section, we should elaborate the uuid generation
> part. Do we have recommendations there? Do we have requirements for the
> uuid (version, uniqueness, etc.)?
>
>
> I'm not sure whether it is worth requiring the UUID format for member id.
> In the protocol, we declare the field "memberId" as "String" rather than
> "uuid". The scope of member id is in "a group", so I guess the collision
> won't be a big issue.
>
> For another, I always wonder why we trust clients to generate "unique"
> transaction id but we worry about generating "unique" member id on client
> side?
>
> Best,
> Chia-Ping
>

Reply via email to