Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (1.0)
Subject: Re: a broker is already registered on path /brokers/ids/1
From: J316 Services <j316services@icloud.com>
In-reply-to: <FD4A656D-4A2C-4AED-8123-2198E524AA66@apache.org>
Date: Tue, 30 Aug 2016 09:35:55 -0400
Cc: users@kafka.apache.org
Content-transfer-encoding: quoted-printable
Message-id: <966A4D16-F7C6-462B-AA11-D05965069D25@icloud.com>
References: 
 <CAALm7OyBBs9gMwR0hXUGKkvPOmy1e2YHc70ZtL-fXpVR82kmjQ@mail.gmail.com>
 <CAALm7OzEUqAjz5hgfT-LUZnB4qf9zpEuz-213DfhceCqgxn7LQ@mail.gmail.com>
 <CAJQG2dCQbZJRkgJPCNO-1Bh-p5fbEo466YyPjfQq2tdy_EwLSg@mail.gmail.com>
 <FD4A656D-4A2C-4AED-8123-2198E524AA66@apache.org>
To: user@zookeeper.apache.org
archived-at: Tue, 30 Aug 2016 13:36:12 -0000

Setup is 3 participants + 1 observer.

We used 3.5.0 for dynamic configs.

What happens when a system forced killed the zookeeper process and it did no=
t have time to clean up ephemeral? Does it recover in that scenario?


Thanks.

Sent from my iPad

> On Aug 30, 2016, at 8:53 AM, Flavio Junqueira <fpj@apache.org> wrote:
>=20
> I think you're saying that the session isn't expiring that and the ephemer=
al isn't getting deleted. Or maybe the session is expiring but the ephemeral=
 isn't being deleted? It'd be great if you could check that the broker sessi=
on is expiring eventually.
>=20
> Since you're on the 3.5 branch, you may want to use 3.5.2-alpha or simply t=
ry 3.4.8 as Harsha suggested.
>=20
> -Flavio
>=20
>> On 29 Aug 2016, at 18:44, Harsha Chintalapani <kafka@harsha.io> wrote:
>>=20
>> how many brokers you've in this cluster. Do you try using a stable
>> zookeeper release like 3.4.8?
>> -Harhsa
>>=20
>>> On Mon, Aug 29, 2016 at 5:21 AM Nomar Morado <nomar.morado@gmail.com> wr=
ote:
>>>=20
>>> we are using kafka 0.9.0.1 and zk 3.5.0-alpha
>>>=20
>>> On Mon, Aug 29, 2016 at 8:12 AM, Nomar Morado <nomar.morado@gmail.com>
>>> wrote:
>>>=20
>>>> we would get this occasionally after a weekend reboot/restart.
>>>>=20
>>>> we tried restarting a couple of times all to naught.
>>>>=20
>>>> we had to delete dk's directory to get his going again.
>>>>=20
>>>> any ideas what might cause this issue and suggestions on how to resolve=

>>>> this?
>>>>=20
>>>>=20
>>>> thanks.
>>>=20
>>>=20
>>>=20
>>> --
>>> Regards,
>>> Nomar Morado
>=20