[
https://issues.apache.org/jira/browse/KAFKA-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587747#comment-13587747
]
Swapnil Ghike commented on KAFKA-774:
-------------------------------------
Yes, your change consolidates everything, which is what I meant. The
indentation change to the big try block is good as well.
If we threw any other exceptions (which I think can be thrown only from
getBrokerInfoFromCache), wouldn't the inner catch blocks convert them to
LeaderNotAvailableException or ReplicaNotAvailableException? So the question
would be which other exceptions are we trying to catch here.
Another question would be in getBrokerInfoFromCache, if we hit a Zk related
exception do we want to convert it to one of LeaderNotAvailableException or
ReplicaNotAvailableException?
> Periodic refresh of topic metadata on the producer does not check for error
> code in the response
> ------------------------------------------------------------------------------------------------
>
> Key: KAFKA-774
> URL: https://issues.apache.org/jira/browse/KAFKA-774
> Project: Kafka
> Issue Type: Bug
> Components: producer
> Affects Versions: 0.8
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Priority: Blocker
> Labels: p1
> Attachments: kafka-774.patch, kafka-774-v2.patch
>
>
> The producer does a periodic refresh of the metadata but marks the attempt as
> successful based only on whether the response was received or not. It does
> not check for error codes in the response. This is probably ok since those
> produce requests will fail and the required topics will enter the list for
> topic metadata refresh in the next attempt. However, it will be good to log
> this since it looks like the metadata was refreshed but actually there could
> be failures.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
