squah-confluent commented on PR #20055:
URL: https://github.com/apache/kafka/pull/20055#issuecomment-3017816001
* I "optimized" away a transition to `UNREVOKED_PARTITIONS` when the
subscription has changed, but the client doesn't own the revoked partitions
anyway. This makes the client re-enter the `STABLE` state 1 heartbeat sooner.
It adds a `ownsRevokedPartitions` call, which has a small performance hit
(compare `stableToUnrevokedPartitionsWithSubscriptionChange` and
`stableToStableWithSubscriptionChange` in the benchmarks below).
* I discovered an interesting behavior when transitioning away from
`UNREVOKED_PARTITIONS`. When the target assignment contains a partition that
was previously pending revocation, the member enters the
`UNRELEASED_PARTITIONS` state, as if another member was holding the partition.
On the next reconcile, I think there is no issue. I haven't tried to fix this
behavior since it existed before this PR.
I reran the benchmarks with the largest parameter sizes:
```
Benchmark
(partitionsPerTopic) (topicCount) Mode Cnt Score Error Units
CurrentAssignmentBuilderBenchmark.stableToStableWithNewTargetAssignment
50 1000 avgt 2.771 ms/op
CurrentAssignmentBuilderBenchmark.stableToStableWithNoChange
50 1000 avgt ≈ 10⁻⁶ ms/op
CurrentAssignmentBuilderBenchmark.stableToStableWithSubscriptionChange
50 1000 avgt 0.046 ms/op
CurrentAssignmentBuilderBenchmark.stableToUnrevokedPartitionsWithSubscriptionChange
50 1000 avgt 0.059 ms/op
JMH benchmarks done
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
