> The problem is that the AdminUtils requires this info to be known client side, but there is no API to get it.
Why does the client side need it? If the broker can auto-create topics, then the broker is aware of the default param. > I think things will be better in 0.11.0 where we have the AdminClient that includes support for both topic CRUD APIs (not just ZK modifications like AdminUtils does) and APIs to get configs. But as far as I'm aware it will still be 2 calls (1 to get the default configs, another to create the topics with those configs). We're a python shop, so generally our interface is the Protocol APIs, not the Java AdminClient. I've been looking forward to using the CRUD APIs for a while. However, it sounds like the CRUD API's still require explicitly including the replication factor param in the CreateTopic call. That's essentially the crux of my question... why does the client ever need to know the default param if the broker is already aware of it? Was this an explicit design decision? On Fri, May 12, 2017 at 6:11 AM, Thomas Becker <tobec...@tivo.com> wrote: > Yes, this has been an issue for some time. The problem is that the > AdminUtils requires this info to be known client side, but there is no API > to get it. I think things will be better in 0.11.0 where we have the > AdminClient that includes support for both topic CRUD APIs (not just ZK > modifications like AdminUtils does) and APIs to get configs. But as far as > I'm aware it will still be 2 calls (1 to get the default configs, another > to create the topics with those configs). > > -Tommy > > ________________________________________ > From: Jeff Widman [j...@netskope.com] > Sent: Thursday, May 11, 2017 7:42 PM > To: users@kafka.apache.org > Subject: Re: Why do I need to specify replication factor when creating a > topic? > > To further clarify: > I'm trying to create topics programmatically. > > We want to run our code against dev/staging/production clusters. In dev, > they are often single-broker clusters. In production, we default to > replication factor of 3. > > So that's why it'd make life easier if it defaulted to the value in > server.properties, rather than our code having to figure out whether it's a > dev vs produciton cluster. > > I'm aware we could hack around this by relying on topic auto-creation, but > we'd rather disable that to prevent topics being accidentally created. > > On Thu, May 11, 2017 at 4:07 PM, Jeff Widman <j...@netskope.com> wrote: > > > When creating a new topic, why do I need to specify the replication > factor > > and number of partitions? > > > > I'd rather than when omitted, Kafka defaults to the value set in > > server.properties. > > > > Was this an explicit design decision? > > > > ________________________________ > > This email and any attachments may contain confidential and privileged > material for the sole use of the intended recipient. Any review, copying, > or distribution of this email (or any attachments) by others is prohibited. > If you are not the intended recipient, please contact the sender > immediately and permanently delete this email and any attachments. No > employee or agent of TiVo Inc. is authorized to conclude any binding > agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo > Inc. may only be made by a signed written agreement. >
