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

Ewen Cheslack-Postava commented on KAFKA-3068:
----------------------------------------------

[~junrao] Right, for people using VIP or DNS, using it as the bootstrap works 
fine. If you're using other discovery mechanisms that don't expose info via DNS 
are stuck using a fixed setting by looking it up once and setting the bootstrap 
servers. (Note also that even DNS only works if you're using some fixed, 
default port. I faced this issue trying to work with Kafka on Mesos because I 
could discover the node the service was running on with mesos-dns, but it was 
using a randomly assigned port. At the time the only way I could figure to make 
this work without opting out of their port management was to use their REST API 
to discover host + port.)

In any case, that is really a much larger KIP discussion, as I said I just 
wanted to gauge level of interest on it. On the solution proposed here, maybe 
go through the quick KIP and see if people agree it makes sense in 0.9.0.1 too 
-- it's true this is a behavioral change, but also for behavior that I'm not 
sure we ever specified or made promises about. [~enothereska] do you want to 
draft up a KIP? Should be a small one.

> 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
>            Assignee: Eno Thereska
>
> 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