Return-Path: X-Original-To: apmail-kafka-users-archive@www.apache.org Delivered-To: apmail-kafka-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1884B10D49 for ; Fri, 11 Oct 2013 21:39:57 +0000 (UTC) Received: (qmail 67459 invoked by uid 500); 11 Oct 2013 21:39:56 -0000 Delivered-To: apmail-kafka-users-archive@kafka.apache.org Received: (qmail 67396 invoked by uid 500); 11 Oct 2013 21:39:56 -0000 Mailing-List: contact users-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@kafka.apache.org Delivered-To: mailing list users@kafka.apache.org Received: (qmail 67388 invoked by uid 99); 11 Oct 2013 21:39:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Oct 2013 21:39:56 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of neha.narkhede@gmail.com designates 74.125.82.176 as permitted sender) Received: from [74.125.82.176] (HELO mail-we0-f176.google.com) (74.125.82.176) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Oct 2013 21:39:51 +0000 Received: by mail-we0-f176.google.com with SMTP id w62so4767930wes.35 for ; Fri, 11 Oct 2013 14:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9Geyef8W+nqWNhnaD/8GezTWw/oT9qNE3jICNbMcN3s=; b=wEvb03oh7BekSvr9BMrPB0IT3/87tgZ7dpwUzQZ+tclL1nWIih+Tyz8LZAEU8NOVo7 vjqCCm4YvxgdVKJh3DRcjHvDQjrJ/TjUztD6LQZh+YjZvhBZe3kxRCqsd8BXZXuea2g0 gpcxM8y0aLgZYgBgEnuLJJBzY7zWR7/+dld4gYvmazvxXensGu/Br8hbWNtOoykpTIvW 1QVM6G3JJKm7/ADkI5M/QVG3RzVqV226Jv9RyBkt5caA7BbOWGlOifBZ6OTvDcoT/fpV XAkVQeffOXg37x8VoDcBQDoklUgaTJHsYRnlpdUodsryYRnJVxbkKVesYiExhpiWecdE X7UA== MIME-Version: 1.0 X-Received: by 10.194.21.131 with SMTP id v3mr3896265wje.44.1381527568987; Fri, 11 Oct 2013 14:39:28 -0700 (PDT) Received: by 10.216.29.130 with HTTP; Fri, 11 Oct 2013 14:39:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Oct 2013 14:39:28 -0700 Message-ID: Subject: Re: Is there a way to pull out kafka metadata from zookeeper? From: Neha Narkhede To: "users@kafka.apache.org" Content-Type: multipart/alternative; boundary=047d7b5d64f2ff3be404e87df382 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b5d64f2ff3be404e87df382 Content-Type: text/plain; charset=ISO-8859-1 >> For each consumer consumes different topic/replica I have to specify those 20 brokers and go over all of them to know which broker is alive. And even worse how about I dynamically add new broker into the cluster and remove the old one TopicMetadataRequest is a batch API and you can get metadata information for either a list of all topics or all topics in the cluster, if you specify an empty list of topics. Adding a broker is not a problem since the metadata request also returns the list of brokers in a cluster. The reason this is better than reading from zookeeper is because the same operation would require multiple zookeeper roundtrips, instead of a single TopicMetadataRequest roundtrip to some kafka broker. Thanks, Neha On Fri, Oct 11, 2013 at 11:30 AM, hsy541@gmail.com wrote: > Thanks guys! > But I feel weird. Assume I have 20 brokers for 10 different topics with 2 > partitions and 2 replicas for each. For each consumer consumes different > topic/replica I have to specify those 20 brokers and go over all of them to > know which broker is alive. And even worse how about I dynamically add new > broker into the cluster and remove the old one. I think it's nice to have a > way to get metadata from zookeeper(centralized coordinator?) directly. > > Best, > Siyuan > > > On Fri, Oct 11, 2013 at 9:12 AM, Neha Narkhede >wrote: > > > If, for some reason, you don't have access to a virtual IP or load > > balancer, you need to round robin once through all the brokers before > > failing a TopicMetadataRequest. So unless all the brokers in your cluster > > are down, this should not be a problem. > > > > Thanks, > > Neha > > > > > > On Thu, Oct 10, 2013 at 10:50 PM, hsy541@gmail.com > > wrote: > > > > > Hi guys, > > > > > > I'm trying to maintain a bunch of simple kafka consumer to consume > > messages > > > from brokers. I know there is a way to send TopicMetadataRequest to > > broker > > > and get the response from the broker. But you have to specify the > broker > > > list to query the information. But broker might not be available > because > > of > > > some failure. My question is is there any api I can call and query > broker > > > metadata for topic/partition directly from zookeeper? I know I can > query > > > that information using zookeeper API. But that's not friendly > > datastructure > > > like the TopicMetadata/PartitionMetadata. Thank you! > > > > > > Best, > > > Siyuan > > > > > > --047d7b5d64f2ff3be404e87df382--