You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Raúl Gutiérrez Segalés <rg...@itevenworks.net> on 2015/10/05 20:01:14 UTC
Re: zookeeper-3.4.7 timeframe
On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
wrote:
> Hi,
>
> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
> wrote:
>
>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
>> wrote:
>>
>>> Hi all,
>>>
>>> sorry about dropping the ball here. So going over the unresolved issues,
>>> I think these ones would be nice to tackle before cutting an RC:
>>>
>>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
>>> ZOOKEEPER-1868)
>>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
>>> given)
>>> (no one has this assigned, I'll try to get a patch out by tomorrow)
>>> * ZOOKEEPER-832: Invalid session id causes infinite loop during
>>> automatic reconnect
>>> (I've asked Rakesh if can wrap it up, if anyone else can help that
>>> would be great)
>>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
>>> immediately following a new epoch
>>> (pinged Flavio to get some feedback)
>>>
>>> Everything else can probably be punted for 3.4.8, unless anyone
>>> disagrees.
>>>
>>
>> One more, which needs to be back-ported from trunk:
>>
>> ZOOKEEPER-1506: Re-try DNS hostname -> IP resolution if node connection
>> fails
>>
>
> There's been some movement in the bug tracker, but ZOOKEEPER-1506 and ZOOKEEPER-832
> still need reviews (hopefully tomorrow, unless someone can beat me to it)
> and I still need to get to ZOOKEEPER-1029.
>
So ZOOKEEPER-1506 is done. Still waiting on ZOOKEEPER-832 and I am hoping
to finally get to ZOOKEEPER-1029 this week (unless someone beats me to it,
which would be much appreciated).
-rgs
Re: zookeeper-3.4.7 timeframe
Posted by Raúl Gutiérrez Segalés <rg...@itevenworks.net>.
On 22 October 2015 at 14:31, Flavio Junqueira <fp...@apache.org> wrote:
> If you have a patch by the end of today for ZK-1029, I'll review it before
> you wake up tomorrow.
>
Flavio fixed this one, so we are good to go!
I will punt everything else to 3.4.8 and cut an RC afterwards :-) Thanks!
-rgs
Re: zookeeper-3.4.7 timeframe
Posted by Flavio Junqueira <fp...@apache.org>.
If you have a patch by the end of today for ZK-1029, I'll review it before you wake up tomorrow.
-Flavio
> On 22 Oct 2015, at 22:27, Raúl Gutiérrez Segalés <rg...@itevenworks.net> wrote:
>
> On 22 October 2015 at 14:07, Flavio Junqueira <fp...@apache.org> wrote:
>
>> Raul,
>>
>> I'd need some time to dig into ZK-832, but from the description I don't
>> think it is a blocker. As I understand this is happening because the server
>> lost persistent state, and this is isn't a common scenario in a replicated
>> deployment. I'm fine with downgrading it from blocker to major/critical.
>>
>> As for ZK-1029, if we know what the problem is, would be difficult to
>> provide a patch?
>>
>
> Sure, we can rework the cleanup path in zookeeper_init(). I just wanted to
> note that it's not what's causing pain for the Mesos project (which looked
> very bad at first), so we shouldn't block on it.
>
> But you are right, it shouldn't be a big patch. I'll propose one later
> today. Hopefully we can have an RC later this week :-)
>
>
> -rgs
Re: zookeeper-3.4.7 timeframe
Posted by Raúl Gutiérrez Segalés <rg...@itevenworks.net>.
On 22 October 2015 at 14:07, Flavio Junqueira <fp...@apache.org> wrote:
> Raul,
>
> I'd need some time to dig into ZK-832, but from the description I don't
> think it is a blocker. As I understand this is happening because the server
> lost persistent state, and this is isn't a common scenario in a replicated
> deployment. I'm fine with downgrading it from blocker to major/critical.
>
> As for ZK-1029, if we know what the problem is, would be difficult to
> provide a patch?
>
Sure, we can rework the cleanup path in zookeeper_init(). I just wanted to
note that it's not what's causing pain for the Mesos project (which looked
very bad at first), so we shouldn't block on it.
But you are right, it shouldn't be a big patch. I'll propose one later
today. Hopefully we can have an RC later this week :-)
-rgs
Re: zookeeper-3.4.7 timeframe
Posted by Rakesh Radhakrishnan <ra...@gmail.com>.
>>>>>I'd need some time to dig into ZK-832, but from the description I
don't think it is a blocker.
Agreed, its not a blocker for 3.4.7 release. This is not a common scenario,
will wait to see more consensus on the proposed algorithm and then push it
in.
-Rakesh
On Fri, Oct 23, 2015 at 2:37 AM, Flavio Junqueira <fp...@apache.org> wrote:
> Raul,
>
> I'd need some time to dig into ZK-832, but from the description I don't
> think it is a blocker. As I understand this is happening because the server
> lost persistent state, and this is isn't a common scenario in a replicated
> deployment. I'm fine with downgrading it from blocker to major/critical.
>
> As for ZK-1029, if we know what the problem is, would be difficult to
> provide a patch?
>
> -Flavio
>
> > On 22 Oct 2015, at 21:57, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
> wrote:
> >
> > On 5 October 2015 at 11:01, Raúl Gutiérrez Segalés <rgs@itevenworks.net
> <ma...@itevenworks.net>>
> > wrote:
> >
> >> On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés <
> rgs@itevenworks.net>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés <
> rgs@itevenworks.net>
> >>> wrote:
> >>>
> >>>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés <
> rgs@itevenworks.net>
> >>>> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> sorry about dropping the ball here. So going over the unresolved
> >>>>> issues, I think these ones would be nice to tackle before cutting an
> RC:
> >>>>>
> >>>>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
> >>>>> ZOOKEEPER-1868)
> >>>>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
> >>>>> given)
> >>>>> (no one has this assigned, I'll try to get a patch out by tomorrow)
> >>>>> * ZOOKEEPER-832: Invalid session id causes infinite loop during
> >>>>> automatic reconnect
> >>>>> (I've asked Rakesh if can wrap it up, if anyone else can help that
> >>>>> would be great)
> >>>>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
> >>>>> immediately following a new epoch
> >>>>> (pinged Flavio to get some feedback)
> >>>>>
> >>>>> Everything else can probably be punted for 3.4.8, unless anyone
> >>>>> disagrees.
> >>>>>
> >>>>
> >>>> One more, which needs to be back-ported from trunk:
> >>>>
> >>>> ZOOKEEPER-1506: Re-try DNS hostname -> IP resolution if node
> connection
> >>>> fails
> >>>>
> >>>
> >>> There's been some movement in the bug tracker, but ZOOKEEPER-1506 and
> ZOOKEEPER-832
> >>> still need reviews (hopefully tomorrow, unless someone can beat me to
> it)
> >>> and I still need to get to ZOOKEEPER-1029.
> >>>
> >>
> >> So ZOOKEEPER-1506 is done. Still waiting on ZOOKEEPER-832 and I am
> hoping
> >> to finally get to ZOOKEEPER-1029 this week (unless someone beats me to
> it,
> >> which would be much appreciated).
> >>
> >
> >
> > Circling back, it turns out that ZOOKEEPER-1029 is actually not the
> cause
> > for MESOS-2186. The fact that we are not properly checking if the locks
> > have been initialized before trying to get the locks is still wrong, but
> > ignoring the return codes from pthread_cond_broadcast and
> > pthread_mutex_lock (EINVAL) is not causing the reported crashers.
> >
> > I propose we punt ZOOKEEPER-1029 and ZOOKEEPER-832 for 3.4.8, so that we
> > can keep moving with the release candidate.
> >
> > Any objections?
> >
> >
> > -rgs
>
>
Re: zookeeper-3.4.7 timeframe
Posted by Flavio Junqueira <fp...@apache.org>.
Raul,
I'd need some time to dig into ZK-832, but from the description I don't think it is a blocker. As I understand this is happening because the server lost persistent state, and this is isn't a common scenario in a replicated deployment. I'm fine with downgrading it from blocker to major/critical.
As for ZK-1029, if we know what the problem is, would be difficult to provide a patch?
-Flavio
> On 22 Oct 2015, at 21:57, Raúl Gutiérrez Segalés <rg...@itevenworks.net> wrote:
>
> On 5 October 2015 at 11:01, Raúl Gutiérrez Segalés <rgs@itevenworks.net <ma...@itevenworks.net>>
> wrote:
>
>> On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
>> wrote:
>>
>>> Hi,
>>>
>>> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
>>> wrote:
>>>
>>>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> sorry about dropping the ball here. So going over the unresolved
>>>>> issues, I think these ones would be nice to tackle before cutting an RC:
>>>>>
>>>>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
>>>>> ZOOKEEPER-1868)
>>>>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
>>>>> given)
>>>>> (no one has this assigned, I'll try to get a patch out by tomorrow)
>>>>> * ZOOKEEPER-832: Invalid session id causes infinite loop during
>>>>> automatic reconnect
>>>>> (I've asked Rakesh if can wrap it up, if anyone else can help that
>>>>> would be great)
>>>>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
>>>>> immediately following a new epoch
>>>>> (pinged Flavio to get some feedback)
>>>>>
>>>>> Everything else can probably be punted for 3.4.8, unless anyone
>>>>> disagrees.
>>>>>
>>>>
>>>> One more, which needs to be back-ported from trunk:
>>>>
>>>> ZOOKEEPER-1506: Re-try DNS hostname -> IP resolution if node connection
>>>> fails
>>>>
>>>
>>> There's been some movement in the bug tracker, but ZOOKEEPER-1506 and ZOOKEEPER-832
>>> still need reviews (hopefully tomorrow, unless someone can beat me to it)
>>> and I still need to get to ZOOKEEPER-1029.
>>>
>>
>> So ZOOKEEPER-1506 is done. Still waiting on ZOOKEEPER-832 and I am hoping
>> to finally get to ZOOKEEPER-1029 this week (unless someone beats me to it,
>> which would be much appreciated).
>>
>
>
> Circling back, it turns out that ZOOKEEPER-1029 is actually not the cause
> for MESOS-2186. The fact that we are not properly checking if the locks
> have been initialized before trying to get the locks is still wrong, but
> ignoring the return codes from pthread_cond_broadcast and
> pthread_mutex_lock (EINVAL) is not causing the reported crashers.
>
> I propose we punt ZOOKEEPER-1029 and ZOOKEEPER-832 for 3.4.8, so that we
> can keep moving with the release candidate.
>
> Any objections?
>
>
> -rgs
Re: zookeeper-3.4.7 timeframe
Posted by Raúl Gutiérrez Segalés <rg...@itevenworks.net>.
On 5 October 2015 at 11:01, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
wrote:
> On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
> wrote:
>
>> Hi,
>>
>> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
>> wrote:
>>
>>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> sorry about dropping the ball here. So going over the unresolved
>>>> issues, I think these ones would be nice to tackle before cutting an RC:
>>>>
>>>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
>>>> ZOOKEEPER-1868)
>>>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
>>>> given)
>>>> (no one has this assigned, I'll try to get a patch out by tomorrow)
>>>> * ZOOKEEPER-832: Invalid session id causes infinite loop during
>>>> automatic reconnect
>>>> (I've asked Rakesh if can wrap it up, if anyone else can help that
>>>> would be great)
>>>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
>>>> immediately following a new epoch
>>>> (pinged Flavio to get some feedback)
>>>>
>>>> Everything else can probably be punted for 3.4.8, unless anyone
>>>> disagrees.
>>>>
>>>
>>> One more, which needs to be back-ported from trunk:
>>>
>>> ZOOKEEPER-1506: Re-try DNS hostname -> IP resolution if node connection
>>> fails
>>>
>>
>> There's been some movement in the bug tracker, but ZOOKEEPER-1506 and ZOOKEEPER-832
>> still need reviews (hopefully tomorrow, unless someone can beat me to it)
>> and I still need to get to ZOOKEEPER-1029.
>>
>
> So ZOOKEEPER-1506 is done. Still waiting on ZOOKEEPER-832 and I am hoping
> to finally get to ZOOKEEPER-1029 this week (unless someone beats me to it,
> which would be much appreciated).
>
Circling back, it turns out that ZOOKEEPER-1029 is actually not the cause
for MESOS-2186. The fact that we are not properly checking if the locks
have been initialized before trying to get the locks is still wrong, but
ignoring the return codes from pthread_cond_broadcast and
pthread_mutex_lock (EINVAL) is not causing the reported crashers.
I propose we punt ZOOKEEPER-1029 and ZOOKEEPER-832 for 3.4.8, so that we
can keep moving with the release candidate.
Any objections?
-rgs