[
https://issues.apache.org/jira/browse/KAFKA-20848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130422#comment-18130422
]
Matthias J. Sax commented on KAFKA-20848:
-----------------------------------------
Thanks [~sunm2n] – I think both are related but independent. This ticket is
about logging relevant config client side, while Kafka-20835 is a problem on
the broker, and both ticket would update different RPCs, so I think it's better
to do two KIPs? Feel free to pick it up either one.
Not 100% sure about the issue with kafka-configs.sh, but again, it might be
another related but independent bug. In doubt, it's related to KAFKA-20848, but
not this ticket.
The fact that a client is not updated w/o a client restart is interesting, but
make sense to me. From my understanding, it would be more complex to allow the
client to auto-update. \cc [~dajac] [~lianetm] – I believe, if we would want to
support client auto-update, we should track it with it's own ticket, and it
might also require a KIP.
> 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)
