[
https://issues.apache.org/jira/browse/KAFKA-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16133274#comment-16133274
]
Onur Karaman commented on KAFKA-5559:
-------------------------------------
Hey [~guozhang]. I read through the PR. I actually had a very similar
discussion over a year ago:
http://markmail.org/message/54ccqas7ty7t4mjt
Your comments on the uniqueness of client ids from
https://github.com/apache/kafka/pull/3328#issuecomment-316137237 conflicts with
Jay's comments from the discussion above.
If we take Jay's definition of client id "a logical name for an application
which (potentially) spans more than one process", then a few of your comments
seem to be incorrect:
# there would definitely be scenarios where multiple clients would exist with
the same client id in the same JVM. This also suggests that KafkaStreams
assigning unique client ids per client within the JVM is actually the wrong
thing to do, and if I recall correctly, KafkaStreams did this purely as a
workaround for the metrics collision issue.
# client ids are not meant to uniquely identify in the request logs which
specific client instance sent the broker the request. It merely tells us which
application sent the request.
# your comment above and the PR discussion suggests clients in the same jvm can
have different AppInfos, which triggers the concern that one client's AppInfos
would potentially replace the other. AppInfo is a fixed value within the JVM. I
think the only way AppInfos can differ across clients of the same JVM is if you
mess around with classloaders.
> Metrics should throw if two client registers with same ID
> ---------------------------------------------------------
>
> Key: KAFKA-5559
> URL: https://issues.apache.org/jira/browse/KAFKA-5559
> Project: Kafka
> Issue Type: Bug
> Components: metrics
> Affects Versions: 0.11.0.0
> Reporter: Matthias J. Sax
> Assignee: Matthias J. Sax
>
> Currently, {{AppInfoParser}} only logs a WARN message when a bean is
> registered with an existing name. However, this should be treated as an error
> and the exception should be rthrown.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
