Re: [ANNOUNCE] Apache ZooKeeper 3.5.5

[Jeff Widman]

Congrats on dropping the "beta" tag, that's a major milestone!

Thanks to the team for all your hard work!

On Mon, May 20, 2019 at 10:06 AM Andor Molnar  wrote:

> The Apache ZooKeeper team is proud to announce Apache ZooKeeper version
> 3.5.5
>
> ZooKeeper is a high-performance coordination service for distributed
> applications. It exposes common services - such as naming,
> configuration management, synchronization, and group services - in a
> simple interface so you don't have to write them from scratch. You can
> use it off-the-shelf to implement consensus, group management, leader
> election, and presence protocols. And you can build on it for your
> own, specific needs.
>
> For ZooKeeper release details and downloads, visit:
> https://zookeeper.apache.org/releases.html
>
> ZooKeeper 3.5.5 Release Notes are at:
> https://zookeeper.apache.org/doc/r3.5.5/releasenotes.html
>
> We would like to thank the contributors that made the release possible.
>
> Regards,
>
> The ZooKeeper Team
>
>
>

-- 

*Jeff Widman*
jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265)
<><

Re: Please Register: ZooKeeper Meetup @ Facebook, Nov 8th 2018

[Jeff Widman]

This is happening this week, correct?

On Fri, Sep 14, 2018 at 8:54 AM Ivan Serdyuk 
wrote:

> Awesome.
>
> I wonder if you are expecting to record your talk.
>
> Ivan
>
> On Fri, Sep 14, 2018 at 2:46 AM Mohamed Jeelani  wrote:
>
> > Your ZooKeeper friends @ Facebook would like to invite you to share and
> > learn what’s new with ZooKeeper.
> >
> > We will not only share what we at Facebook have been up to, but we have
> > exciting talks from speakers from the ZooKeeper community lined up who
> are
> > eager to share what they've been working on as well. And of course, we've
> > got some cool swag for you :-)
> >
> > When: November 8th 2018, 5pm – 8pm (Talks: 5pm - 7pm; Networking & Happy
> > Hour: 7pm - 8pm)
> > Where: Facebook HQ - MPK 16, 1 Hacker Way, Menlo Park, CA
> > We will have remote viewing locations in our Facebook Seattle office, and
> > the event will also be live streamed. You can indicate how you'd like to
> > attend on the registration page.
> >
> > Please register here - https://zookeeperatfb.splashthat.com/
> >
> > We look forward to seeing you soon!
> >
> > ZooKeeper Friends @ Facebook
> >
>


-- 

*Jeff Widman*
jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265)
<><

Re: Upgrade required Java version to 1.8 on 3.5+

[Jeff Widman]

+1 from me to using Java 8 or even going all the way to 9 for the 3.5
release branch.

On Mar 7, 2018 8:17 AM, "Shawn Heisey"  wrote:

> On 3/7/2018 4:04 AM, Andor Molnar wrote:
>
>> I've quickly checked some of the major components that are heavy Zk
>> clients:
>>
>> Hadoop/HDFS = 1.8 required
>> HBase = 1.8 required
>> Kafka = 1.7 required (has some 1.8 and 1.9 bindings)
>> Hive = 1.8 required
>> Curator = 1.7 required (has 1.8-only async module to take advantage of
>> Java
>> lambdas)
>> Solr  = 1.8
>>
>> As always, your feedback is much appreciated.
>>
>
> I come from the Solr world.
>
> Lucene/Solr started requiring Java 7 with the release of 4.8.0, announced
> on 2014-04-28.
>
> Lucene/Solr started requiring Java 8 with the release of 6.0.0, announced
> on 2016-04-08.
>
> The general reaction each time one of these major changes was discussed
> seemed to be "oh, finally!  it's about time!"  I get the strong sense that
> Lucene committers really want to use the new language features, and feel
> limited when they can't. Historically, there have been a few changes
> committed that failed to compile when the officially supported minimum JDK
> version was used.  The authors probably should have noticed the problem,
> but sometimes don't because they're using updated toolchains.
>
> How do the committers on this project generally feel about needing to
> avoid using Java 8 features?  If they don't feel limited, there's probably
> no reason to update the requirement.  If however they feel that they could
> write better code with a refresh, then given general industry trends, it
> probably is time to consider updating the requirement.  Maybe you will want
> to accelerate plans for a 4.0 release, and update the requirement there.
>
> Another piece of information to think about:  Oracle isn't providing
> public support/bugfixes for Java 7 any more.  To get support, Oracle must
> be paid.  Java 8 is going to reach that same milestone in January 2019, so
> within the next year or so, we are going to begin seeing a lot of projects
> updating to a minimum of Java 9.
>
> Thanks,
> Shawn
>
>

Any technical reasons that the 3.5.x series is still in beta?

[Jeff Widman]

Is there any technical reasons the 3.5.x series is still in beta?

Looking through existing issues, I don't see anything critical that makes
3.5.x less stable than the 3.4.x series...

If the answer is "no tech reason, just the social reason that no maintainer
has had time to push through a full stable release", then I understand that
perfectly...

-- 

*Jeff Widman*
jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265)
<><

Re: Why are ephemeral nodes written to disk?

[Jeff Widman]

Thank you. I did not realize sessions could continue even if the ensemble
was shutdown.

On Jan 17, 2018 3:28 PM, "Patrick Hunt" <ph...@apache.org> wrote:

> On Tue, Jan 9, 2018 at 12:38 PM, Jeff Widman <j...@jeffwidman.com> wrote:
>
> > Ephemeral nodes only exist for the life of the client session.
> >
> > As far as I understand, by definition, a client session ends when the
> > entire zookeeper ensemble goes down.
> >
> > So I would expect that ephemeral nodes are only written to memory, not
> > disk. The ephemeral nodes would be sync'd across machines as a client
> > session can span multiple connections if a single zk server fails, but
> once
> > the ensemble is down there is no need to recover the ephemeral nodes from
> > disk.
> >
> > However, when I looked at a zookeeper ensemble that is 99% ephemeral
> nodes,
> > I see a bunch of disk I/O from the zookeeper processes. So it appears
> that
> > ephemeral nodes are still written to disk...
> >
> > Why is this?
> >
>
> Ephemeral znodes are treated just like persistent znodes in the sense that
> a quorum of nodes need to agree to any change. As such the znode is written
> to the transaction log.
>
> "a client session ends when the entire zookeeper ensemble goes down"
>
> is not correct. A client session ends either when a client closes it's
> session explicitly or the ZK quorum leader decides that the session has
> expired (which is based on the negotiated session timeout). Only while a
> leader is active can a session be expired (or closed for that matter). When
> you shutdown an ensemble the sessions are maintained. If you were to, for
> example, shut down an ensemble for an hour and then restart it the sessions
> would still be active. The clock would "reset" when the new leader was
> elected. If the client session is still active the session would continue,
> any ephemeral znodes would still exist.
>
> Patrick
>
>
> >
> > --
> >
> > *Jeff Widman*
> > jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265)
> > <><
> >
>

Why are ephemeral nodes written to disk?

[Jeff Widman]

Ephemeral nodes only exist for the life of the client session.

As far as I understand, by definition, a client session ends when the
entire zookeeper ensemble goes down.

So I would expect that ephemeral nodes are only written to memory, not
disk. The ephemeral nodes would be sync'd across machines as a client
session can span multiple connections if a single zk server fails, but once
the ensemble is down there is no need to recover the ephemeral nodes from
disk.

However, when I looked at a zookeeper ensemble that is 99% ephemeral nodes,
I see a bunch of disk I/O from the zookeeper processes. So it appears that
ephemeral nodes are still written to disk...

Why is this?

-- 

*Jeff Widman*
jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265)
<><