Re: Consider increasing the default reserved.broker.max.id

Any thoughts on adding a "broker.id.generation.enabled" configuration for auto generating broker ids? If we added this and defaulted it to false, users who upgrade don't need to worry about the reserved.broker.max.id configuration since it will not be used. Users using the standard/old way of manu

Re: Consider increasing the default reserved.broker.max.id

I agree that many people id their brokers differently and increasing the default will only handle a subset of those schemes. Though I think increasing it to some reasonable value may help decrease issues drastically regardless. I also think some longer term fix that avoids collisions all together

Re: Consider increasing the default reserved.broker.max.id

Which other numbering schemes do we want to be able to un-break by increasing this default? For example, I know some people use the IP address with dots removed -- we'd have to use a very large # to make sure that worked. Before making another change, it'd be good to know what other schemes people

Re: Consider increasing the default reserved.broker.max.id

On Fri, Dec 18, 2015 at 4:44 PM, Grant Henke wrote: > There is some discussion on KAFKA-1070 > around the design > choice > and compatibility. The value 1000 was thrown out as a quick example but it > was never discussed beyond that. The discussi

Re: Consider increasing the default reserved.broker.max.id

I created KAFKA-3012 to track this change. I am open to other strategies to reduce/eliminate collisions too. On Fri, Dec 18, 2015 at 10:44 AM, Grant Henke wrote: > There is some discussion on KAFKA-1070 >

Re: Consider increasing the default reserved.broker.max.id

There is some discussion on KAFKA-1070 around the design choice and compatibility. The value 1000 was thrown out as a quick example but it was never discussed beyond that. The discussion also sites a few cases where a value of 1000 would cause issu

Re: Consider increasing the default reserved.broker.max.id

Hi Grant, On Fri, Dec 18, 2015 at 4:07 PM, Grant Henke wrote: > I have seen a few issues utilizing the default value of > reserved.broker.max.id=1000 in existing clusters during upgrades. 1000 seems a bit low to me too and a larger number seems safer. It would be good to understand the reasoni