On 5 October 2015 at 11:01, Raúl Gutiérrez Segalés <r...@itevenworks.net> wrote:
> On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés <r...@itevenworks.net> > wrote: > >> Hi, >> >> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés <r...@itevenworks.net> >> wrote: >> >>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés <r...@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