[ 
https://issues.apache.org/jira/browse/KAFKA-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085663#comment-15085663
 ] 

Ismael Juma commented on KAFKA-3068:
------------------------------------

[~enothereska], I agree that a better solution would involve cluster identity, 
but that seems like a bigger change. The reason is that the new clients should 
not access ZK directly, only via the Kafka brokers (security being a major 
reason). With regards to your point (1), I also thought of that, but failed 
brokers are also an issue when a client is started, so there is a good reason 
to include a reasonable number of brokers in the bootstrap brokers config.

It seems like if we favour safety and there is no easy way to make use of 
cluster identity, then we should do the bootstrap brokers config change now and 
explore the better solution in a subsequent JIRA. Thoughts?

> NetworkClient may connect to a different Kafka cluster than originally 
> configured
> ---------------------------------------------------------------------------------
>
>                 Key: KAFKA-3068
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3068
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 0.9.0.0
>            Reporter: Jun Rao
>
> In https://github.com/apache/kafka/pull/290, we added the logic to cache all 
> brokers (id and ip) that the client has ever seen. If we can't find an 
> available broker from the current Metadata, we will pick a broker that we 
> have ever seen (in NetworkClient.leastLoadedNode()).
> One potential problem this logic can introduce is the following. Suppose that 
> we have a broker with id 1 in a Kafka cluster. A producer client remembers 
> this broker in nodesEverSeen. At some point, we bring down this broker and 
> use the host in a different Kafka cluster. Then, the producer client uses 
> this broker from nodesEverSeen to refresh metadata. It will find the metadata 
> in a different Kafka cluster and start producing data there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to