[
https://issues.apache.org/jira/browse/KAFKA-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fernando Blanch Calvete updated KAFKA-13144:
--------------------------------------------
Description:
As a suggestion, it would be very useful that when obtaining the metadata
information of the topic and there are errors, to add them to the log at WARN
level (for example) instead of DEBUG. Since in productive environments we do
not usually have the log at DEBUG level and if errors of this type occur it is
very useful to know them at the moment.
For example, in the class
*org.apache.kafka.clients.consumer.internals.Fetcher*, in the line 394, where
the errors are traced in DEBUG it would be very useful for us that they are at
least in WARN, to identify *UNKNOWN_TOPIC_OR_PARTITION* errors and to know the
name of the topic that causes it.
EDITED:
On the other hand, when the client makes the call
"*RequestFuture<ClientResponse> future = sendMetadataRequest(request);*" (line
374 of *org.apache.kafka.clients.consumer.internals.Fetcher*) to the broker to
get the response, if the broker is set to "*allowAutoTopicCreation=false*" and
the topic does not exist, the response *UNKNOWN_TOPIC_TOPIC_OR_PARTITION* error
has no topic name information, and this exception is thrown without any
information to the client in this way:
{code:java}
Caused by: org.apache.kafka.common.errors.UnknownTopicOrPartitionException:
This server does not host this topic-partition.{code}
It is scenarios with many consumer/producer configurations it is very useful to
know the name of the topic that is causing the problem.
was:
As a suggestion, it would be very useful that when obtaining the metadata
information of the topic and there are errors, to add them to the log at WARN
level (for example) instead of DEBUG. Since in productive environments we do
not usually have the log at DEBUG level and if errors of this type occur it is
very useful to know them at the moment.
For example, in the class
*org.apache.kafka.clients.consumer.internals.Fetcher*, in the line 394, where
the errors are traced in DEBUG it would be very useful for us that they are at
least in WARN, to identify *UNKNOWN_TOPIC_OR_PARTITION* errors and to know the
name of the topic that causes it.
> Change the LOG level from DEBUG to WARN/ERROR for error traces when obtaining
> topic metadata
> --------------------------------------------------------------------------------------------
>
> Key: KAFKA-13144
> URL: https://issues.apache.org/jira/browse/KAFKA-13144
> Project: Kafka
> Issue Type: Improvement
> Components: clients
> Affects Versions: 2.8.0
> Reporter: Fernando Blanch Calvete
> Priority: Major
>
> As a suggestion, it would be very useful that when obtaining the metadata
> information of the topic and there are errors, to add them to the log at WARN
> level (for example) instead of DEBUG. Since in productive environments we do
> not usually have the log at DEBUG level and if errors of this type occur it
> is very useful to know them at the moment.
> For example, in the class
> *org.apache.kafka.clients.consumer.internals.Fetcher*, in the line 394, where
> the errors are traced in DEBUG it would be very useful for us that they are
> at least in WARN, to identify *UNKNOWN_TOPIC_OR_PARTITION* errors and to know
> the name of the topic that causes it.
>
> EDITED:
> On the other hand, when the client makes the call
> "*RequestFuture<ClientResponse> future = sendMetadataRequest(request);*"
> (line 374 of *org.apache.kafka.clients.consumer.internals.Fetcher*) to the
> broker to get the response, if the broker is set to
> "*allowAutoTopicCreation=false*" and the topic does not exist, the response
> *UNKNOWN_TOPIC_TOPIC_OR_PARTITION* error has no topic name information, and
> this exception is thrown without any information to the client in this way:
> {code:java}
> Caused by: org.apache.kafka.common.errors.UnknownTopicOrPartitionException:
> This server does not host this topic-partition.{code}
> It is scenarios with many consumer/producer configurations it is very useful
> to know the name of the topic that is causing the problem.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
