Fixing this in ZK won't be enough though. We'll need this included in a stable release that we'll then bump Kafka's dependencies to include. I doubt this KIP will be deprecated shortly even if the ZK bug is fixed immediately.
On Tue, Oct 31, 2017 at 4:59 PM Jeff Widman <j...@jeffwidman.com> wrote: > Agree with Stephane that it's worth at least taking a shot at trying to get > ZOOKEEPER-2184 fixed rather than adding a config that will be deprecated in > the not-too distant future. > > I know Zookeeper development feels more like the turtle than the hare these > days, but Kafka is a high-visibility project, so there's a decent chance > you'll be able to get the attention of the zookeeper maintainers to get a > patch merged and possibly even a new release cut incorporating this fix. > > On Tue, Oct 31, 2017 at 3:28 PM, Stephane Maarek < > steph...@simplemachines.com.au> wrote: > > > Hi Jun, > > > > Thanks for the reply. > > > > 1) The reason I'm asking about it is I wonder if it's not worth focusing > > the development efforts on taking ownership of the existing PR ( > > https://github.com/apache/zookeeper/pull/150) to fix ZOOKEEPER-2184, > > rebase it and have it merged into the ZK codebase shortly. I feel this > KIP > > might introduce a setting that could be deprecated shortly and confuse > the > > end user a bit further with one more knob to turn. > > > > 3) I'm not sure if I fully understand, sorry for the beginner's question: > > if the default timeout is infinite, then it won't change anything to how > > Kafka works from today, does it? (unless I'm missing something sorry). If > > not set to infinite, then we introduce the risk of a whole cluster > shutting > > down at once? > > > > Thanks, > > Stephane > > > > On 31/10/17, 1:00 pm, "Jun Rao" <j...@confluent.io> wrote: > > > > Hi, Stephane, > > > > Thanks for the reply. > > > > 1) Fixing the issue in ZK will be ideal. Not sure when it will happen > > though. Once it's fixed, we can probably deprecate this config. > > > > 2) That could be useful. Is there a java api to do that at runtime? > > Also, > > invalidating DNS cache doesn't always fix the issue of unresolved > > host. In > > some of the cases, human intervention is needed. > > > > 3) The default timeout is infinite though. > > > > Jun > > > > > > On Sat, Oct 28, 2017 at 11:48 PM, Stephane Maarek < > > steph...@simplemachines.com.au> wrote: > > > > > Hi Jun, > > > > > > I think this is very helpful. Restarting Kafka brokers in case of > > zookeeper > > > host change is not a well known operation. > > > > > > Few questions: > > > 1) would it not be worth fixing the problem at the source ? This > has > > been > > > stuck for a while though, maybe a little push would help : > > > https://issues.apache.org/jira/plugins/servlet/mobile# > > issue/ZOOKEEPER-2184 > > > > > > 2) upon recreating the zookeeper object , is it not possible to > > invalidate > > > the DNS cache so that it resolves the new hostname? > > > > > > 3) could the cluster be down in this situation: one migrates an > > entire > > > zookeeper cluster to new machines (one by one). The quorum is still > > alive > > > without downtime, but now every broker in a cluster can't resolve > > zookeeper > > > at the same time. They all shut down at the same time after the new > > > time-out setting. > > > > > > Thanks ! > > > Stéphane > > > > > > On 28 Oct. 2017 9:42 am, "Jun Rao" <j...@confluent.io> wrote: > > > > > > > Hi, Everyone, > > > > > > > > We created "KIP-217: Expose a timeout to allow an expired ZK > > session to > > > be > > > > re-created". > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > > > 217%3A+Expose+a+timeout+to+allow+an+expired+ZK+session+ > > to+be+re-created > > > > > > > > Please take a look and provide your feedback. > > > > > > > > Thanks, > > > > > > > > Jun > > > > > > > > > > > > > > > > > > -- > > *Jeff Widman* > jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265) > <>< >
