[
https://issues.apache.org/jira/browse/KAFKA-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115702#comment-15115702
]
Jun Rao commented on KAFKA-3068:
--------------------------------
[~ewencp], having a pluggable discovery service may be reasonable. However, one
will need some kind of entry points to connect to the external discovery
service. Then one has to answer the same question: how to keep the entry points
to external services valid all the time. If one has to rely upon things like
VIP or DNS mapping there, we probably should just recommend people to use those
on the bootstrap servers in the first place.
Also, for the fix, my feeling is that falling back to bootstrap servers is a
subtle change of behavior from 0.8.2 producer and probably should go through a
KIP discussion too, since it can have implication on people who generate
bootstrap servers from an external service.
Alternatively, we can just revert the behavior in 0.9.0.1 to 0.8.2 (i.e., just
wait when all brokers are not connectable). This may affect people who are
using a small cluster and when there is a significant number of broker
failures. However, this should be relatively rare. Then, we can start a
separate KIP discussion in 0.9.1 to see what's the best way to fix this
completely.
> 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)
