[
https://issues.apache.org/jira/browse/KAFKA-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111240#comment-18111240
]
Matthias J. Sax edited comment on KAFKA-20719 at 9/3/26 6:26 PM:
-----------------------------------------------------------------
This ticket cannot be back ported... the fix relies on few features added to
4.4.0 which are not available in older versions.
For setting versions: We don't set all versions, but only "earlierst affected"
and "first fixed". Ie, if affected version is 4.2.0, it means all later version
are also affected as long as there is not "fix version". Ie, if we set "fix
version" 4.3.0 and 4.2.2, it implies that 4.2.1 is also affected and it's fixed
also din 4.3.1, 4.3.2, 4.4.0, 4.5.0. and 4.2.3, 4.2.4... but we don't need to
set all these version explicitly. Does this make sense?
It's not wrong to set any of these version, but it just busy work.
The other point is: if we want to fix something for an unreleased version, we
should only set the version on the "fixed version" field if the ticket is still
open, indicating: when we resolve this ticket, we need to backport.
If a ticket is already resolve, we should only add a new fix version _after_
the cherry-pick landed. For a closed ticket, a set fix version mean, the branch
contains the fix.
was (Author: mjsax):
This ticket cannot be back ported... the fix relies on few features added to
4.4.0 which are not available in older versions.
For setting versions: We don't set all versions, but only "earlierst affected"
and "first fixed". Ie, if affected version is 4.2.0, it means all later version
are also affected as long as there is not "fix version". Ie, if we set "fix
version" 4.3.0 and 4.2.2, it implies that 4.2.1 is also affected and it's fixed
also din 4.3.1, 4.3.2, 4.4.0, 4.5.0. and 4.2.3, 4.2.4... but we don't need to
set all these version explicitly. Does this make sense?
It's not wrong to set any of these version, but it just busy work.
The other point is: if we want to fix something for an unreleased version, we
should only set the version on the "fixed version" field if the ticket is still
open, indicating: when we resolve this ticket, we need to backport.
If a ticket is already resolve, we should only add a new fix version _after_
the cherry-pick landed. For a close ticket, a set fix version mean, the branch
already contains the fix.
> "Streams" group sticky assignor not sticky at startup
> -----------------------------------------------------
>
> Key: KAFKA-20719
> URL: https://issues.apache.org/jira/browse/KAFKA-20719
> Project: Kafka
> Issue Type: Bug
> Components: group-coordinator, streams
> Affects Versions: 4.2.0, 4.3.0
> Reporter: Matthias J. Sax
> Assignee: Ziyun Fu
> Priority: Critical
> Fix For: 4.4.0
>
>
> For "streams" groups (KIP-1071), the sticky-assignor is not sticky at startup
> of a new KS instance/client.
> In the "classic" protocol, a newly starting client encodes what task
> directories it finds in its local state directory as part of the rebalance
> metadata. This allows the "classic" client-side sticky assignor to re-assign
> tasks to previous clients, meeting the goal of being sticky.
> In contrast, for "streams" group no such information is encoded. A starting
> instance correctly sends empty previous assignment on its initial "join group
> heartbeat" (with epoch=0). While the group coordinator does pass in the
> "current/previous assignment" into the sticky assignor, new clients/threads
> get a new memberId, and thus previous state cannot be re-assigned in a sticky
> manner on startup. (Note, static membership might address this, but it's also
> not yet supported for "streams" group:
> https://issues.apache.org/jira/browse/KAFKA-20169)
> To fix this issue, we should encode offset information(derived from the local
> task offset checkpoint) via `taskOffsetSum` field in the "join group
> heartbeat", and update the sticky-assignor to use this data.
> This ticket is blocked by https://issues.apache.org/jira/browse/KAFKA-20116
> which does add support for `taskOffsetSum` client and broker side already, to
> support warmup tasks. After KAFKA-20116 was completed, this ticket would need
> to fix the sticky-assignor itself to use the newly available data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
