[
https://issues.apache.org/jira/browse/KAFKA-20848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130117#comment-18130117
]
이선민 commented on KAFKA-20848:
-----------------------------
[^analyze.py] [^run.sh] [^summary.txt] [~mjsax] [~chia7712] I reproduced the
situation this ticket describes, and wanted to check how it relates to
KAFKA-20835 before going further.
On trunk (a3444d8b32, single KRaft node), I set
consumer.session.timeout.ms=60000 and consumer.heartbeat.interval.ms=12000 on a
consumer group, then restarted the broker with
group.consumer.max.session.timeout.ms=30000 and
group.consumer.max.heartbeat.interval.ms=6000:
* At startup, the broker logs a WARN that both values are capped, to 30000 and
6000.
* {{kafka-configs.sh --describe}} still returns 60000 and 12000. The describe
path builds the GroupConfig from the stored overrides, without the evaluation
step that caps them.
* The consumer logs the heartbeat interval it receives (6000ms), but nothing
indicates that a value was capped, and the session timeout is not sent to the
client.
* After I killed the consumer, the member was fenced 30.0s after the broker
processed its last heartbeat, so 30000 is the value in effect.
In this reproduction, the broker log shows the effective session timeout, while
the client does not receive it and describe still reports the stored value. The
reproduction script, analysis script, and result summary are attached.
KAFKA-20835 discusses adding a warning to the alter-config response when a
stored value differs from the effective one, with a KIP planned. This ticket
covers the same mismatch from the client side, through the heartbeat response,
and the describe output seems relevant to both. Would you prefer to cover
KAFKA-20835 and KAFKA-20848 in a single KIP, or handle them separately? If
separately, and if nobody is already working on KAFKA-20848, I'd be interested
in drafting a KIP for it.
> Consider to surface group-level misconfigurations client side
> -------------------------------------------------------------
>
> Key: KAFKA-20848
> URL: https://issues.apache.org/jira/browse/KAFKA-20848
> Project: Kafka
> Issue Type: Improvement
> Components: clients, consumer, group-coordinator, streams
> Reporter: Matthias J. Sax
> Priority: Minor
> Labels: needs-kip
> Attachments: analyze.py, run.sh, summary.txt
>
>
> With the new KIP-848 based consumer/share/streams groups, many configs moved
> from the client into the broker.
> Some of these config are sent back to the client (as the client really uses
> them), and we recently started to log them
> ([https://github.com/apache/kafka/pull/22749] and
> [https://github.com/apache/kafka/pull/22730]) for improved observability.
> However, there is a few more configs which have broker defaults plus group
> level overwrites, and they are not visible on the client (only
> describe-config or describe-group would reveal them). At the same time, the
> broker might overwrite group-level config (clamping to min/max for example),
> what is not visible either on the client.
> For Kafka Streams, we have one hybrid config (client + broker combination)
> ([https://github.com/apache/kafka/pull/22213]) and introduced and error code
> in the StreamsHeartbeatResponse to surface a misconfiguration client side.
> The ides of this ticket is, to do a similar thing for _all_ group level
> configs. We would add _all_ effective group config to the HB response for
> logging, with relogging if changed. Additionally, if a value is clamped, and
> the set group-config is not the effective config, we return some error code,
> allowing the client to also log a WARNING about it.
> This would be a protocol change, so thus we need a KIP.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
