ore options for parallel processing and
> ordering
>
> Regards, Paul
>
> From: Artem Livshits
> Date: Friday, 24 January 2025 at 5:29 am
> To: users@kafka.apache.org
> Subject: Re: JoinGroup API response timing.
> [You don't often get email from alivsh..
consumer for higher throughput with less
consumers/partitions – there are more options for parallel processing and
ordering
Regards, Paul
From: Artem Livshits
Date: Friday, 24 January 2025 at 5:29 am
To: users@kafka.apache.org
Subject: Re: JoinGroup API response timing.
[You don't ofte
; available consumers for high throughput – if a consumer fails or is
> kicked
> > off the group because it times out etc then the remainder of the
> consumers
> > are rebalanced across the partitions etc. Paul
> >
> > From: Chain Head
> > Date: Wednesday,
if a consumer fails or is kicked
> off the group because it times out etc then the remainder of the consumers
> are rebalanced across the partitions etc. Paul
>
> From: Chain Head
> Date: Wednesday, 22 January 2025 at 5:19 pm
> To: users@kafka.apache.org
> Subject: Re: J
consumers are
rebalanced across the partitions etc. Paul
From: Chain Head
Date: Wednesday, 22 January 2025 at 5:19 pm
To: users@kafka.apache.org
Subject: Re: JoinGroup API response timing.
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
Thanks for the explanation.
Slight
Thanks for the explanation.
Slight digression and perhaps a silly question w.r.t. consumers.
Since multiple groups are possible, at a high level, the broker effectively
sends data of a given topic-partition to multiple consumers while keeping
track of offsets. So, why not let consumers specify th
Hi,
Thanks for the follow up.
By "classic" I meant the protocol implemented by the SyncGroup/JoinGroup
API [1]. It's a general group protocol that is still fully supported in
Kraft, and at this time has no intention of being deprecated.
It's called "classic" to distinguish it from the newer KIP-8
Thanks.
By "classic" you mean pre-KRaft consensus? What is the "current" Kafka
Group protocol?
Best regards.
On Tue, Jan 21, 2025 at 9:55 PM Greg Harris
wrote:
> Hi,
>
> Yes you are correct. The "classic" Kafka Group Protocol is a synchronizing
> barrier for all members.
> All JoinGroup member
Hi,
Yes you are correct. The "classic" Kafka Group Protocol is a synchronizing
barrier for all members.
All JoinGroup member responses are returned after all JoinGroup member
requests are received.
Thanks,
Greg
On Tue, Jan 21, 2025 at 7:10 AM Chain Head wrote:
> Assume that three consumers of
Assume that three consumers of a certain group want to connect to a broker
for a topic with 3 partitions. After the FindCoordinator API is done, the
consumers send JoinGroup. Since the broker cannot know in advance how many
consumers are expected to join, it waits group.initial.rebalance.delay.ms
b
10 matches
Mail list logo
