I completely agree with Patrick on this and would like to see this a blocker as well. We've seen this several times internally with our own rolling reboot tests. This occurrence was at a customer site so it was much more alarming.
On Thu, Oct 3, 2013 at 11:10 AM, FPJ <[email protected]> wrote: > It was a blocker until early this morning, but I thought it was really a > corner case so I re-classified it. Make it a blocker back if you'd like. > > -Flavio > > > -----Original Message----- > > From: Patrick Hunt [mailto:[email protected]] > > Sent: 03 October 2013 18:08 > > To: UserZooKeeper > > Cc: Marshall McMullen; DevZooKeeper > > Subject: Re: ZOOKEEPER-1732 workaround? > > > > Based on the fact that we've gotten two such reports on this I've upped > the > > priority on this issue (to critical, arguably it should be a blocker). I > think I've > > seen this at at least one customer site. IMO we should try to fix this in > 3.4.6. > > > > Patrick > > > > On Thu, Oct 3, 2013 at 10:03 AM, Marshall McMullen > > <[email protected]> wrote: > > > Flavio made a suggestion on the jira to simply restart the current > leader. > > > It worked! Within a few seconds everything sorted itself out. Thanks > > > so much for the amazingly prompt reply. Love this community! :). > > > > > > > > > On Thu, Oct 3, 2013 at 10:46 AM, Marshall McMullen < > > > [email protected]> wrote: > > > > > >> We've just hit ZOOKEEPER-1732 (server cannot join an established > > >> ensemble with quorum) and are trying to find a workaround since we do > > >> not have that patch applied. Has anyone had any success working around > > this issue? > > >> Perhaps restarting all ZK servers to force a new round of leader > election? > > >> Any other ideas? Really appreciate any advice... > > >> > > >> Thanks! > > >> > >
