[
https://issues.apache.org/jira/browse/KAFKA-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15111627#comment-15111627
]
Guozhang Wang edited comment on KAFKA-3088 at 1/21/16 11:49 PM:
----------------------------------------------------------------
Yeah, I just meant that the server today rely on clients guaranteeing not-null
clients in the past time, and of course that is not the case for all clients.
We are just lucky that this problem is not exposed in older versions. So now we
either need to:
1) educate all client developers to guarantee this themselves (technically very
hard), and let servers reject null / empty-string client-ids.
2) do not enforce client developers to do so, and let servers assign client-id
themselves.
Personally I am not in favor of 2) as it will make trouble shooting quite hard
since we cannot tell too much from client-id "producer-5", while adding
hostnames / etc into auto generated clientId is not safe as we can have
multiple clients on the same clients, etc. So I would rather go with option 1),
that when users get an returned error server they will realize "oh I forgot to
specify the client-ids".
BTW, I am adding a "NotNull" Validator in ConfigDef as part of
https://issues.apache.org/jira/browse/KAFKA-3121, this may cover the java
clients as we discussed here.
EDIT: just realized that today we already "validate" required configs as long
as we do not provide a default value. So will not add the above Validator.
was (Author: guozhang):
Yeah, I just meant that the server today rely on clients guaranteeing not-null
clients in the past time, and of course that is not the case for all clients.
We are just lucky that this problem is not exposed in older versions. So now we
either need to:
1) educate all client developers to guarantee this themselves (technically very
hard), and let servers reject null / empty-string client-ids.
2) do not enforce client developers to do so, and let servers assign client-id
themselves.
Personally I am not in favor of 2) as it will make trouble shooting quite hard
since we cannot tell too much from client-id "producer-5", while adding
hostnames / etc into auto generated clientId is not safe as we can have
multiple clients on the same clients, etc. So I would rather go with option 1),
that when users get an returned error server they will realize "oh I forgot to
specify the client-ids".
BTW, I am adding a "NotNull" Validator in ConfigDef as part of
https://issues.apache.org/jira/browse/KAFKA-3121, this may cover the java
clients as we discussed here.
> 0.9.0.0 broker crash on receipt of produce request with empty client ID
> -----------------------------------------------------------------------
>
> Key: KAFKA-3088
> URL: https://issues.apache.org/jira/browse/KAFKA-3088
> Project: Kafka
> Issue Type: Bug
> Components: producer
> Affects Versions: 0.9.0.0
> Reporter: Dave Peterson
> Assignee: Jun Rao
>
> Sending a produce request with an empty client ID to a 0.9.0.0 broker causes
> the broker to crash as shown below. More details can be found in the
> following email thread:
> http://mail-archives.apache.org/mod_mbox/kafka-users/201601.mbox/%3c5693ecd9.4050...@dspeterson.com%3e
> [2016-01-10 23:03:44,957] ERROR [KafkaApi-3] error when handling request
> Name: ProducerRequest; Version: 0; CorrelationId: 1; ClientId: null;
> RequiredAcks: 1; AckTimeoutMs: 10000 ms; TopicAndPartition: [topic_1,3] -> 37
> (kafka.server.KafkaApis)
> java.lang.NullPointerException
> at
> org.apache.kafka.common.metrics.JmxReporter.getMBeanName(JmxReporter.java:127)
> at
> org.apache.kafka.common.metrics.JmxReporter.addAttribute(JmxReporter.java:106)
> at
> org.apache.kafka.common.metrics.JmxReporter.metricChange(JmxReporter.java:76)
> at
> org.apache.kafka.common.metrics.Metrics.registerMetric(Metrics.java:288)
> at org.apache.kafka.common.metrics.Sensor.add(Sensor.java:177)
> at org.apache.kafka.common.metrics.Sensor.add(Sensor.java:162)
> at
> kafka.server.ClientQuotaManager.getOrCreateQuotaSensors(ClientQuotaManager.scala:209)
> at
> kafka.server.ClientQuotaManager.recordAndMaybeThrottle(ClientQuotaManager.scala:111)
> at
> kafka.server.KafkaApis.kafka$server$KafkaApis$$sendResponseCallback$2(KafkaApis.scala:353)
> at
> kafka.server.KafkaApis$$anonfun$handleProducerRequest$1.apply(KafkaApis.scala:371)
> at
> kafka.server.KafkaApis$$anonfun$handleProducerRequest$1.apply(KafkaApis.scala:371)
> at
> kafka.server.ReplicaManager.appendMessages(ReplicaManager.scala:348)
> at kafka.server.KafkaApis.handleProducerRequest(KafkaApis.scala:366)
> at kafka.server.KafkaApis.handle(KafkaApis.scala:68)
> at
> kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:60)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
