Re: ZooKeeper Meetup @ Facebook - Jan 29th

[Edward Ribeiro]

+1 on video conferencing. :)

I am particularly excited to see Jordan's proposal! :)

Cheers,
Edward

Em sex, 10 de jan de 2020 18:42, Jordan Zimmerman <
jor...@jordanzimmerman.com> escreveu:

> If there’s video conferencing available I could do a remote presention on
> the ideas I have for gRPC support.
>
> 
> Jordan Zimmerman
>
> > On Jan 10, 2020, at 3:01 PM, Mohamed Jeelani  wrote:
> >
> > Lets Meetup!  (Please Register at
> https://zkmeetup2020.splashthat.com/)
> >
> > Your ZooKeeper friends @ Facebook would like to invite you to our office
> to share and learn whats 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, including from Cloudera, Twitter,
> Salesforce and SJSU who are eager to share what they've been working on
> >
> > ...and of course we've got some cool swag for you as well.
> >
> > January 29th 2020 4.30pm - 8pm
> >
> > Facebook Campus, MPK 28
> > Talks: 5pm - 7pm
> > Networking & Happy Hour: 7pm - 8pm
> >
> > This event will be live streamed via Facebook Live at
> https://www.facebook.com/zkmeetup
> >
> > Please Register at https://zkmeetup2020.splashthat.com/
> >
>

Re: [ANNOUNCE] New ZooKeeper committer: Fangmin Lv

[Edward Ribeiro]

Congratulations Fangmin!

Edward

Em qua, 7 de nov de 2018 22:35, Patrick Hunt  Kudos Fangmin!
>
> Patrick
>
> On Wed, Nov 7, 2018 at 4:31 PM Michael Han  wrote:
>
> > The Apache ZooKeeper PMC recently extended committer karma to Fangmin
> > and he has accepted. Fangmin has made some great contributions and we
> > are looking forward to even more :)
> >
> >
> > Congratulations and welcome aboard, Fangmin!
> >
> > Michael
> >
>

Re: Zookeeper at Twitter by Micheal

[Edward Ribeiro]

Congrats, Michael,

Really cool blog post. :)

Em seg, 15 de out de 2018 05:26, Norbert Kalmar
 escreveu:

> Good blog post!
> Can't wait for the PRs ;)
> I'm very positive about ZooKeeper's future (heard lot of talks lately about
> etcd overthrowing ZooKeeper - no chance :) )
>
> Norbert
>
> On Sun, Oct 14, 2018 at 10:39 PM Andor Molnár  wrote:
>
> > Great stuff Michael!
> >
> >
> > Andor
> >
> >
> >
> > On 10/14/2018 12:26 AM, Enrico Olivelli wrote:
> > > Hi Michael,
> > > I just stepped into this very interesting post !
> > >
> > >
> >
> https://blog.twitter.com/engineering/en_us/topics/infrastructure/2018/zookeeper-at-twitter.html
> > >
> > > Thank you
> > > Enrico
> >
> >
>

Re: DISCUSSION: Drop PDF support in documentation

[Edward Ribeiro]

+1 about dropping the PDF support.

Edward

On Fri, Oct 5, 2018 at 5:30 AM Norbert Kalmar 
wrote:
>
> Sounds logical to me, dropping pdf support / generation.
> +1
>
> On Thu, Oct 4, 2018 at 10:47 PM Michael Han  wrote:
>
> > +1 on dropping support for PDF documents. Most if not all of the other
> > apache projects only provide html documents.
> >
> > On Wed, Oct 3, 2018 at 1:18 AM Enrico Olivelli 
> > wrote:
> >
> > > Il giorno mer 3 ott 2018 alle ore 09:34 Tamas Penzes
> > >  ha scritto:
> > > >
> > > > Hi All,
> > > >
> > > > As part of "ZOOKEEPER-925 Consider maven site generation to replace
our
> > > > forrest site and documentation generation" I have implemented
> > > > "ZOOKEEPER-3153 Create MarkDown files and build process for them".
> > > >
> > > > The solution would replace the old Forrest based document creation
with
> > > > MarkDown based one, which is easier to create, edit, maintain, etc.
> > > > I also had the goal that the new solution should work out of the
box,
> > > > without the need to install anything on the build machine. You just
> > check
> > > > out the project and are already able to build and generate the
project,
> > > > including the documentation.
> > > >
> > > > From the .md files I still create HTML content for the webpage (just
> > try
> > > > out `mvn clean install` and check zookeeper-docs/target/html/) but I
> > > > haven't found a proper way to create PDFs directly from the .md
files.
> > > >
> > > > As far as I know PDFs are not really used, so it would be enough to
add
> > > the
> > > > .md and .html content to the tarball and we could skip the PDF
> > > generation.
> > > >
> > > > What do you think about it?
> > > > Is there anyone who would need PDFs?
> > >
> > > I (and my company) don't need them.
> > > IMHO you don't need a PDF version of ZK docs
> > >
> > > so +1 for dropping
> > >
> > > Enrico
> > >
> > >
> > > >
> > > > Thanks, Tamaas
> > >
> >

[jira] [Commented] (ZOOKEEPER-1990) suspicious instantiation of java Random instances

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581380#comment-16581380
 ] 

Edward Ribeiro commented on ZOOKEEPER-1990:
---

Hi [~nkalmar], I raised the possibility of using _ThreadLocalRandom_, so my two 
cents: we can call _Random()_ (option 1), imo. _ThreadLocalRandom_ advantage is 
avoiding thread contention and overhead of sharing a global math.Random among 
many threads, but I don't think this is a issue with current ZK codebase.

> suspicious instantiation of java Random instances
> -
>
> Key: ZOOKEEPER-1990
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1990
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Hunt
>Assignee: Norbert Kalmar
>Priority: Critical
> Fix For: 3.6.0, 3.5.5
>
>
> It's not clear to me why we are doing this, but it looks very suspicious. Why 
> aren't we just calling "new Random()" in these cases? (even for the tests I 
> don't really see it - typically that would just be for repeatability)
> {noformat}
> ag "new Random[ \t]*\(" .
> src/java/main/org/apache/zookeeper/ClientCnxn.java
> 817:private Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/client/StaticHostProvider.java
> 75:   sourceOfRandomness = new Random(System.currentTimeMillis() ^ 
> this.hashCode());
> 98:sourceOfRandomness = new Random(randomnessSeed);
> src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java
> 420:rand = new Random(java.lang.Thread.currentThread().getId()
> src/java/main/org/apache/zookeeper/server/SyncRequestProcessor.java
> 64:private final Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java
> 537:Random r = new Random(id ^ superSecret);
> 554:Random r = new Random(sessionId ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/WatchLeakTest.java
> 271:Random r = new Random(SESSION_ID ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
> 151:Random rand = new Random(Thread.currentThread().getId());
> 258:Random rand = new Random(Thread.currentThread().getId());
> 288:Random rand = new Random(Thread.currentThread().getId());
> src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java
> 40:private Random r = new Random(1);
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ZOOKEEPER-3105) Character coding problem occur when create a node using python3

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558353#comment-16558353
 ] 

Edward Ribeiro commented on ZOOKEEPER-3105:
---

Could you please post a code snippet that reproduces this error?

Best,

Edward

> Character coding problem occur when create a node using python3
> ---
>
> Key: ZOOKEEPER-3105
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3105
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 3.5.0
> Environment: linux
>Reporter: yang hao
>Priority: Major
> Fix For: 3.5.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> when creating a node using python3,  InvalidACLException occurs all the time. 
> it`s caused by imcompatible way of parsing acl passed through python3 api.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New ZooKeeper committer: Andor Molnar

[Edward Ribeiro]

Congratulations, Andor! :)

E.

Em sex, 8 de jun de 2018 10:48, Patrick Hunt  escreveu:

> The Apache ZooKeeper PMC recently extended committer karma to Andor and he
> has accepted. Andor has made some great contributions and we are looking
> forward to even more :)
>
> Congratulations and welcome aboard Andor!
>
> Patrick
>

Re: Apache ZooKeeper meetup May 9th in Palo Alto?

[Edward Ribeiro]

Oh, I missed the streaming. :(

Was it recorded? The slides are available anywhere?

On Thu, May 10, 2018 at 2:22 PM, Srikanth Viswanathan 
wrote:

> Thanks for the presentations! Will the slides be posted somewhere?
>
> On Thu, May 10, 2018, 09:36 Prasanth Mathialagan <
> prasanthmathiala...@gmail.com> wrote:
>
> > Gosh!! I missed it!! May be next time :)
> >
> > On Thu, May 10, 2018 at 8:24 AM, Andor Molnar 
> wrote:
> >
> > > Thanks everybody for joining.
> > > It was great to see you folks in person and talk.
> > >
> > > Regards,
> > > Andor
> > >
> > >
> > >
> > > On Wed, May 9, 2018 at 9:44 PM, Patrick Hunt  wrote:
> > >
> > > > On Wed, May 9, 2018 at 9:24 PM, Jeff Widman 
> > wrote:
> > > >
> > > > > Many thanks to Patrick, Andor and the rest of the Cloudera team for
> > > > hosting
> > > > > us tonight. I appreciated the chance to compare notes with other
> > users
> > > > and
> > > > > also discuss some of where the future of Zookeeper is heading.
> > > > >
> > > > >
> > > > Thanks everyone for attending. It was great to see some old as well
> as
> > > new
> > > > faces.
> > > >
> > > >
> > > > > Cheers,
> > > > > Jeff
> > > > >
> > > > > PS: Apologies to the remote folks for the dead sound at the
> end--the
> > > > > hangout connection to the conference room sound system died, and
> > nobody
> > > > in
> > > > > the room knew how to reconnect it.
> > > > >
> > > > >
> > > > Yea, sorry about that. IT did some magic to connect the hangout into
> > the
> > > > internal audio system of the room and I wasn't able to figure out the
> > > codes
> > > > they used.
> > > >
> > > > Regards,
> > > >
> > > > Patrick
> > > >
> > > >
> > > > >
> > > > > On Fri, Apr 27, 2018 at 6:40 PM, Srikanth Viswanathan <
> > > > > srikant...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Confirming attendance from Seattle as well. Looking forward to
> the
> > > > > > presentations. Particularly excited for the containers talk!
> > > > > >
> > > > > > On Thu, Apr 26, 2018, 10:29 Patrick Hunt 
> wrote:
> > > > > >
> > > > > > > Ok, great. I have two speakers already lined up: one on ZK and
> > > > > containers
> > > > > > > and another on ZK failure modes and recovery. If you haven't
> > > reached
> > > > > out
> > > > > > to
> > > > > > > me yet and you have something to talk about please LMK asap.
> > > > > > >
> > > > > > > I believe we will have video conference available but I'm not
> > > > entirely
> > > > > > sure
> > > > > > > yet - I will try.
> > > > > > >
> > > > > > > I'll finalize things and send out a more detailed agenda.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Patrick
> > > > > > >
> > > > > > > On Thu, Apr 26, 2018 at 1:33 AM, Shivam Goel <
> > shivam@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Count me in !!
> > > > > > > >
> > > > > > > > On Mon, Apr 23, 2018 at 10:08 AM Patrick Hunt <
> > ph...@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi folks. I am interested in hosting a ZooKeeper meetup May
> > 9th
> > > > in
> > > > > > > > > Cloudera's Palo Alto offices. It's been a while since we
> last
> > > got
> > > > > > > > together,
> > > > > > > > > lots of recent changes and some big plans, new additions to
> > the
> > > > PMC
> > > > > > and
> > > > > > > > > committer lists, new contributors.
> > > > > > > > >
> > > > > > > > > I was hoping to use the mailing lists to gauge interest.
> > Please
> > > > > reply
> > > > > > > if
> > > > > > > > > you
> > > > > > > > > think you would be able to attend or would prefer a
> different
> > > > date.
> > > > > > > Also
> > > > > > > > > let me know if there's something you would like to present
> to
> > > the
> > > > > > > group.
> > > > > > > > > Food
> > > > > > > > > and beer will be provided.
> > > > > > > > >
> > > > > > > > > Looking forward to hearing from everyone.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Patrick
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > *Jeff Widman*
> > > > > jeffwidman.com  | 740-WIDMAN-J
> > (943-6265)
> > > > > <><
> > > > >
> > > >
> > >
> >
>

Re: Question on merge script

[Edward Ribeiro]

FYI, the merge script was created in the Spark project then ported to Kafka
project. And Kafka version was ported to ZK. :)

Ed

Em qua, 9 de mai de 2018 19:46, Patrick Hunt  escreveu:

> I believe we forked the script and the process/docs off another TLP,
> perhaps spark or kafka? Might be worth checking what they are currently
> doing/changed.
>
> Patrick
>
> On Wed, May 9, 2018 at 1:45 PM, Flavio Junqueira  wrote:
>
> > Thanks for the feedback, Pat. I think the wiki page with merge script
> > instructions needs updating. I'll explore it a bit further and will
> update
> > it.
> >
> > -Flavio
> >
> > > On 9 May 2018, at 20:05, Patrick Hunt  wrote:
> > >
> > > On Wed, May 9, 2018 at 1:18 AM, Flavio Junqueira 
> wrote:
> > >
> > >> Hey Michael,
> > >>
> > >> I was trying to merge yesterday a PR generated against branch-3.5, and
> > >> fetching the PR branch did not give me the merge script. I ended up
> > asking
> > >> the contributor to change the target branch to master so that I avoid
> > any
> > >> small hacks with the merge script.
> > >>
> > >>
> > > fwiw that's not the workflow I use. I always fetch the latest repo
> > content,
> > > then switch to the master and use the script to merge/push a PR. It
> > doesn't
> > > matter which PR or branch you want to merge, you just run the script
> off
> > > master and it handles the rest. If the branch/PR is off 3.4 it all just
> > > works.
> > >
> > >
> > >> We should consider doing the following two things, and let me know if
> it
> > >> makes sense:
> > >> 1- Clarifying that if a change is supposed to go to both branch-3.5
> and
> > >> master, the PR should be against master
> > >>
> > >
> > > As long as it applies cleanly to master and br35 (etc...) this is not
> > > really necessary. You use the merge script to merge it into the target
> > > branch, then after you push that change to apache git repo it will ask
> > you
> > > if you want to merge to other branches. Typically I would ask the OP to
> > > post multiple PRs if there are conflicts. I don't usually commit to
> just
> > > one branch if the change is necessary for multiple branches and there
> are
> > > conflicts. (I wait for all the PRs covering all the branches cleanly)
> > >
> > >
> > >> 2- Perhaps merging to branch-3.5 so that I see the script when I
> fetch a
> > >> PR branch off branch-3.5. This is unusual, but it is not unreasonable
> > that
> > >> we have eventually PRs for branch-3.5 only.
> > >>
> > >> I'm focusing on 3.5, but the same reasoning applies to 3.4.
> > >>
> > >>
> > > I always just start with master checked out and run the script. Seems
> > fine
> > > to me and it means we don't need to maintain multiple versions of the
> > > scripts and keep them in sync. What's the benefit of doing otw?
> > >
> > > Patrick
> > >
> > >
> > >> -Flavio
> > >>
> > >>
> > >>> On 9 May 2018, at 01:49, Michael Han  wrote:
> > >>>
> > >>> Hi Flavio,
> > >>>
> > >>> The merge script is branch agnostic - it only cares about the pull
> > >> request
> > >>> number. As long as in the pull request the correct target branch is
> > >>> specified, the merge script will do its job by merging the change to
> > the
> > >>> specified target branch. I guess we could commit the same script to
> > >>> branch-3.5 but the current script in master should be able to do what
> > you
> > >>> asked.
> > >>>
> > >>> On Tue, May 8, 2018 at 4:06 PM, Flavio Junqueira 
> > wrote:
> > >>>
> >  Could anyone remind me why we don't have the merge script on
> > branch-3.5?
> >  Say I have a change that targets branch-3.5 alone. Shouldn't I be
> able
> > >> to
> >  have a PR that targets branch-3.5 and use the merge script?
> > 
> >  Thanks,
> >  -Flavio
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Cheers
> > >>> Michael
> > >>
> > >>
> >
> >
>

Re: Txn logs and snapshots in git repo

[Edward Ribeiro]

Oh, nice. Thanks, Andor!

Ed

On Wed, May 9, 2018 at 1:52 PM, Andor Molnar <an...@cloudera.com> wrote:

> Hi Ed,
>
> Static data used by unit tests.
>
> Andor
>
>
>
> On Wed, May 9, 2018 at 9:46 AM, Edward Ribeiro <edward.ribe...@gmail.com>
> wrote:
>
> > I am updating my local repo and noticed some transaction logs and
> snapshots
> > files in src/java/test/data/invalidsnap/version-2. Are those files
> static
> > data used by unit tests or just artifacts accidentally pushed to the
> repo?
> >
> > ls -lah src/java/test/data/invalidsnap/version-2/
> >
> > total 936
> > drwxr-xr-x  11 edward  staff   374B May  9 13:34 .
> > drwxr-xr-x   3 edward  staff   102B Oct  8  2016 ..
> > -rw-r--r--   1 edward  staff58K Oct  8  2016 log.1
> > -rw-r--r--   1 edward  staff89K Oct  8  2016 log.274
> > -rw-r--r--   1 edward  staff   184B May  9 13:34 log.42
> > -rw-r--r--   1 edward  staff48K Oct  8  2016 log.63b
> > -rw-r--r--   1 edward  staff   296B Oct  8  2016 snapshot.0
> > -rw-r--r--   1 edward  staff55K Oct  8  2016 snapshot.272
> > -rw-r--r--   1 edward  staff55K Oct  8  2016 snapshot.273
> > -rw-r--r--   1 edward  staff   140K Oct  8  2016 snapshot.639
> > -rw-r--r--   1 edward  staff   4.7K Oct  8  2016 snapshot.83f
> >
> > By the way, they are on master, branch-3.4 and branch-3.5
> >
> > Cheers,
> > Edward
> >
>

Txn logs and snapshots in git repo

[Edward Ribeiro]

I am updating my local repo and noticed some transaction logs and snapshots
files in src/java/test/data/invalidsnap/version-2. Are those files static
data used by unit tests or just artifacts accidentally pushed to the repo?

ls -lah src/java/test/data/invalidsnap/version-2/

total 936
drwxr-xr-x  11 edward  staff   374B May  9 13:34 .
drwxr-xr-x   3 edward  staff   102B Oct  8  2016 ..
-rw-r--r--   1 edward  staff58K Oct  8  2016 log.1
-rw-r--r--   1 edward  staff89K Oct  8  2016 log.274
-rw-r--r--   1 edward  staff   184B May  9 13:34 log.42
-rw-r--r--   1 edward  staff48K Oct  8  2016 log.63b
-rw-r--r--   1 edward  staff   296B Oct  8  2016 snapshot.0
-rw-r--r--   1 edward  staff55K Oct  8  2016 snapshot.272
-rw-r--r--   1 edward  staff55K Oct  8  2016 snapshot.273
-rw-r--r--   1 edward  staff   140K Oct  8  2016 snapshot.639
-rw-r--r--   1 edward  staff   4.7K Oct  8  2016 snapshot.83f

By the way, they are on master, branch-3.4 and branch-3.5

Cheers,
Edward

Re: [SUGGESTION] JvmPauseMonitor in ZooKeeper

[Edward Ribeiro]

+1. Sounds really nice to have feature. Let's open a ticket and open a PR.
:)

Ed

Em qua, 9 de mai de 2018 11:15, Norbert Kalmar 
escreveu:

> Hi,
>
> I just got a tip that we could improve on the logging in ZooKeeper. After a
> ZK crash, or client timeout sometimes it's hard to determine from the logs
> what happened. Knowing if ZK was responsive at the time would help a lot.
> For example, ZK might spend a lot of time waiting on GC (there is still
> some misconception that ZK is a storage).
>
> To help detect this, HADOOP already has a great tool called JVM Pause
> Monitor. (As the name suggest, it can be also used for monitoring, but it
> also helps post-mortem in a lot of cases). Basically it has a daemon that
> sleeps for one second, and if the sleep time exceeds the 1s by more than
> the threshold (1s: INFO, 10s: WARN by default - this can be configurable in
> our case, see below), it will alert/make a log entry. It can also monitor
> the time GC took.
>
> Now, this class is in the HADOOP-common. I wouldn't want to depend on
> Hadoop-common because of this one feature/class (it is actually a single
> class). Since this is a straightforward implementation, and in the past
> five years the few commits it had is nothing really serious, I think we
> could just copy this class in ZooKeeper, and introduce it as a configurable
> feature, by default it can be off.
>
> The class:
>
> https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/JvmPauseMonitor.java
>
> What do You think?
>
> Regards,
> Norbert
>

Re: Discover LEADER from JMX

[Edward Ribeiro]

Sent before finishing the previous email. Only to complement, the
findLeader() could have been as below, but this change is only a nitty
detail and totally irrelevant to the questions you are asking. :)

/**
 * Returns the address of the node we think is the leader.
 */
protected QuorumServer findLeader() {

// Find the leader by id
long currentLeader = self.getCurrentVote().getId();

QuorumServer leaderServer = self.getView().get(currentLeader);

if (leaderServer == null) {
LOG.warn("Couldn't find the leader with id = {}", currentLeader);
}
return leaderServer;
}

Edward

On Wed, May 9, 2018 at 9:29 AM, Edward Ribeiro <edward.ribe...@gmail.com>
wrote:

> Hi Enrico,
>
> Well, I am not an expert on QuorumPeer either (not an expert on anything,
> really), but maybe it's the variable and method below?
>
> - QuorumPeer --
>
> /**
>  * This is who I think the leader currently is.
>  */
> volatile private Vote currentVote;
>
> public synchronized Vote getCurrentVote(){
> return currentVote;
> }
>
> ---
>
>
> Then it's a matter of calling quorumPeer.getCurrentVote().getId() and
> quorumPeer.getServerState()?
>
> Btw, the Learner class has this handy method below (self is a QuorumPeer):
>
>  Learner 
>
> /**
>  * Returns the address of the node we think is the leader.
>  */
> protected QuorumServer findLeader() {
> QuorumServer leaderServer = null;
> // Find the leader by id
> Vote current = self.getCurrentVote();
> for (QuorumServer s : self.getView().values()) {
> if (s.id == current.getId()) {
> leaderServer = s;
> break;
> }
> }
> if (leaderServer == null) {
> LOG.warn("Couldn't find the leader with id = "
> + current.getId());
> }
> return leaderServer;
> }
>
> ---
>
> By the way, as a side note, the map traversal could be changed by:
>
> 
>
> if (self.getView().contains(current.getId()) {
>
> }
>
> ---
>
>
>
> You can see above this method the quorumPeer.getView() returns a Map<sid,
> QuorumServer> as below:
>
> -QuorumPeer -
>
> /**
>  * A 'view' is a node's current opinion of the membership of the entire
>  * ensemble.
>  */
> public Map<Long,QuorumPeer.QuorumServer> getView() {
> return Collections.unmodifiableMap(getQuorumVerifier().
> getAllMembers());
> }
>
> -
>
>
> And then it retrieves the QuorumServer that has many more information
> about the node besides the sid (InetSocketAddress, hostname, etc). :)
>
>
> Cheers,
> Edward
>
> On Wed, May 9, 2018 at 8:50 AM, Enrico Olivelli <eolive...@gmail.com>
> wrote:
>
>> So I am trying to create a patch in order to expose on JMX the id of the
>> current "leader" (on the JVM of a follower)
>>
>> I am trying to find in ZK which is the variable which holds the ID of the
>> current leader.
>> I am new to the internal of QuorumPeer
>>
>> Can someone give me some hint ?
>>
>> Enrico
>>
>> Il giorno mar 8 mag 2018 alle ore 10:08 Ansel Zandegran <
>> ansel.zandeg...@infor.com> ha scritto:
>>
>> > Hi,
>> > That is possible with 4 letter commands. We are using it now. In 3.5.x
>> it
>> > is going to be removed in favour of admin server (embedded web server).
>> > We are running in an environment where it’s not possible to run JMX or
>> > embedded web servers.
>> >
>> > So I am wondering if there is another way? It would be nice to have this
>> > info as a znode.
>> >
>> > Best regards,
>> > Ansel
>> >
>> > > On 8 May 2018, at 09:55, Flavio Junqueira <f...@apache.org> wrote:
>> > >
>> > > Hi Enrico,
>> > >
>> > > You can determine the state of a server it via 4-letter commands.
>> Would
>> > that work for you?
>> > >
>> > > -Flavio
>> > >
>> > >> On 8 May 2018, at 09:09, Enrico Olivelli <eolive...@gmail.com>
>> wrote:
>> > >>
>> > >> Hi,
>> > >> is there any way to see in JMX which is the leader of a ZooKeeper
>> > cluster?
>> > >>
>> > >> My problem is: given access to any of the nodes of the cluster I
>> want to
>> > >> know from JMX which is the current leader.
>> > >> It seems to me that this information is not available, you can know
>> > only if
>> > >> the local node is Leader or Follower.
>> > >>
>> > >> Cheers
>> > >> Enrico
>> > >
>> >
>> >
>>
>
>

Re: Discover LEADER from JMX

[Edward Ribeiro]

Hi Enrico,

Well, I am not an expert on QuorumPeer either (not an expert on anything,
really), but maybe it's the variable and method below?

- QuorumPeer --

/**
 * This is who I think the leader currently is.
 */
volatile private Vote currentVote;

public synchronized Vote getCurrentVote(){
return currentVote;
}

---


Then it's a matter of calling quorumPeer.getCurrentVote().getId() and
quorumPeer.getServerState()?

Btw, the Learner class has this handy method below (self is a QuorumPeer):

 Learner 

/**
 * Returns the address of the node we think is the leader.
 */
protected QuorumServer findLeader() {
QuorumServer leaderServer = null;
// Find the leader by id
Vote current = self.getCurrentVote();
for (QuorumServer s : self.getView().values()) {
if (s.id == current.getId()) {
leaderServer = s;
break;
}
}
if (leaderServer == null) {
LOG.warn("Couldn't find the leader with id = "
+ current.getId());
}
return leaderServer;
}

---

By the way, as a side note, the map traversal could be changed by:



if (self.getView().contains(current.getId()) {

}

---



You can see above this method the quorumPeer.getView() returns a Map as below:

-QuorumPeer -

/**
 * A 'view' is a node's current opinion of the membership of the entire
 * ensemble.
 */
public Map getView() {
return Collections.unmodifiableMap(getQuorumVerifier().getAllMembers());
}

-


And then it retrieves the QuorumServer that has many more information about
the node besides the sid (InetSocketAddress, hostname, etc). :)


Cheers,
Edward

On Wed, May 9, 2018 at 8:50 AM, Enrico Olivelli  wrote:

> So I am trying to create a patch in order to expose on JMX the id of the
> current "leader" (on the JVM of a follower)
>
> I am trying to find in ZK which is the variable which holds the ID of the
> current leader.
> I am new to the internal of QuorumPeer
>
> Can someone give me some hint ?
>
> Enrico
>
> Il giorno mar 8 mag 2018 alle ore 10:08 Ansel Zandegran <
> ansel.zandeg...@infor.com> ha scritto:
>
> > Hi,
> > That is possible with 4 letter commands. We are using it now. In 3.5.x it
> > is going to be removed in favour of admin server (embedded web server).
> > We are running in an environment where it’s not possible to run JMX or
> > embedded web servers.
> >
> > So I am wondering if there is another way? It would be nice to have this
> > info as a znode.
> >
> > Best regards,
> > Ansel
> >
> > > On 8 May 2018, at 09:55, Flavio Junqueira  wrote:
> > >
> > > Hi Enrico,
> > >
> > > You can determine the state of a server it via 4-letter commands. Would
> > that work for you?
> > >
> > > -Flavio
> > >
> > >> On 8 May 2018, at 09:09, Enrico Olivelli  wrote:
> > >>
> > >> Hi,
> > >> is there any way to see in JMX which is the leader of a ZooKeeper
> > cluster?
> > >>
> > >> My problem is: given access to any of the nodes of the cluster I want
> to
> > >> know from JMX which is the current leader.
> > >> It seems to me that this information is not available, you can know
> > only if
> > >> the local node is Leader or Follower.
> > >>
> > >> Cheers
> > >> Enrico
> > >
> >
> >
>

[jira] [Resolved] (ZOOKEEPER-3035) what does these opeartion code mean

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro resolved ZOOKEEPER-3035.
---
Resolution: Not A Problem

> what does these opeartion code mean
> ---
>
> Key: ZOOKEEPER-3035
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3035
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: liyuzhou
>Priority: Minor
>
> I'm reading the source code, but I often can not understand the operation 
> code mean in OpCode.java. For example , the sync operation code is 9, but I 
> can't understand what does this mean, and the source code has nothing about 
> the code description. Do we have some wiki or document abount operation code?
> {code:java}
> public interface OpCode {
> public final int notification = 0;
> public final int setACL = 7;
> public final int getChildren = 8;
> public final int sync = 9;
> public final int ping = 11;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ZOOKEEPER-3035) what does these opeartion code mean

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467666#comment-16467666
 ] 

Edward Ribeiro commented on ZOOKEEPER-3035:
---

Please, don't open Jira issues to ask questions. Use ZK mailing lists (user 
and/or dev) to ask such things.

 

The OpCode is the number that identifies a given operation (getData, setData, 
exists, etc) on the wire protocol. When the message is serialized/deserialize 
the value tells what kind of message it is.

> what does these opeartion code mean
> ---
>
> Key: ZOOKEEPER-3035
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3035
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: liyuzhou
>Priority: Minor
>
> I'm reading the source code, but I often can not understand the operation 
> code mean in OpCode.java. For example , the sync operation code is 9, but I 
> can't understand what does this mean, and the source code has nothing about 
> the code description. Do we have some wiki or document abount operation code?
> {code:java}
> public interface OpCode {
> public final int notification = 0;
> public final int setACL = 7;
> public final int getChildren = 8;
> public final int sync = 9;
> public final int ping = 11;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ZOOKEEPER-3006) Potential NPE in ZKDatabase#calculateTxnLogSizeLimit

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro reassigned ZOOKEEPER-3006:
-

Assignee: Edward Ribeiro

> Potential NPE in ZKDatabase#calculateTxnLogSizeLimit
> 
>
> Key: ZOOKEEPER-3006
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3006
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: lujie
>    Assignee: Edward Ribeiro
>Priority: Major
>
> I have found a potential NPE in ZKDatabase#calculateTxnLogSizeLimit:
>  
> {code:java}
> //ZKDatabase
> public long calculateTxnLogSizeLimit() {
> long snapSize = 0;
> try {
> snapSize = snapLog.findMostRecentSnapshot().length();
> } catch (IOException e) {
> LOG.error("Unable to get size of most recent snapshot");
> }
> return (long) (snapSize * snapshotSizeFactor);
> }
> {code}
>  in FileTxnSnapLog#findMostRecentSnapshot(), it will return the result of  
> FileSnap#findMostRecentSnapshot:
> {code:java}
> // called by FileTxnSnapLog#findMostRecentSnapshot()
> public File findMostRecentSnapshot() throws IOException {
> List files = findNValidSnapshots(1);
> if (files.size() == 0) {
> return null;
> }
> return files.get(0);
> }
> {code}
> So it will return null when the files sizes is 0, but 
> ZKDatabase#calculateTxnLogSizeLimit has no null checker
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Upgrade 3.5 and trunk to Java8

[Edward Ribeiro]

+1 (non-binding)

On Sat, Mar 24, 2018 at 1:42 PM, Brian Nixon 
wrote:

> +1 (non-binding)
>
> On Fri, Mar 23, 2018 at 2:15 AM, Mark Fenes  wrote:
>
> > +1
> >
> >
> > On Thu, Mar 22, 2018 at 6:57 PM, Andor Molnar 
> wrote:
> >
> > > Hi all,
> > >
> > > Let's start the vote on upgrading to Java8.
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-3002
> > >
> > > *Shall we upgrade the minimum required Java version to compile and run
> > > ZooKeeper on 3.5 and master branches to Java 1.8?*
> > >
> > > Please cast your vote by replying 'Yes' or 'No' to this thread.
> > >
> > > Thanks,
> > > Andor
> > >
> >
>

[jira] [Commented] (ZOOKEEPER-1990) suspicious instantiation of java Random instances

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412656#comment-16412656
 ] 

Edward Ribeiro commented on ZOOKEEPER-1990:
---

As you are tackling this issue, it would be nice to evaluate the use of 
ThreadLocalRandom ( 
[https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadLocalRandom.html]
 ) instead of Random, if possible. It's been available since JDK7 and offers 
less contention and overhead.

> suspicious instantiation of java Random instances
> -
>
> Key: ZOOKEEPER-1990
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1990
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Critical
> Fix For: 3.5.4, 3.6.0
>
>
> It's not clear to me why we are doing this, but it looks very suspicious. Why 
> aren't we just calling "new Random()" in these cases? (even for the tests I 
> don't really see it - typically that would just be for repeatability)
> {noformat}
> ag "new Random[ \t]*\(" .
> src/java/main/org/apache/zookeeper/ClientCnxn.java
> 817:private Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/client/StaticHostProvider.java
> 75:   sourceOfRandomness = new Random(System.currentTimeMillis() ^ 
> this.hashCode());
> 98:sourceOfRandomness = new Random(randomnessSeed);
> src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java
> 420:rand = new Random(java.lang.Thread.currentThread().getId()
> src/java/main/org/apache/zookeeper/server/SyncRequestProcessor.java
> 64:private final Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java
> 537:Random r = new Random(id ^ superSecret);
> 554:Random r = new Random(sessionId ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/WatchLeakTest.java
> 271:Random r = new Random(SESSION_ID ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
> 151:Random rand = new Random(Thread.currentThread().getId());
> 258:Random rand = new Random(Thread.currentThread().getId());
> 288:Random rand = new Random(Thread.currentThread().getId());
> src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java
> 40:private Random r = new Random(1);
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New ZooKeeper committer: Abraham Fine

[Edward Ribeiro]

Awesome news!!!

I've been absent from ZK community for some time now (hopefully back soon),
but even from afar I see Abe's has been pretty active and a driving force
on the community.

Congratulations, Abe! :)

Edward
Em 30 de jan de 2018 6:29 AM, "Andor Molnar"  escreveu:

> Great news!
>
> Congratulations Abe!
>
>
>
> On Tue, Jan 30, 2018 at 1:22 AM, Patrick Hunt  wrote:
>
> > The Apache ZooKeeper PMC recently extended committer karma to Abe and he
> > has accepted. Abe has made some great contributions and we are looking
> > forward to even more :)
> >
> > Congratulations and welcome aboard Abe!
> >
> > Patrick
> >
>

[jira] [Comment Edited] (ZOOKEEPER-2921) fsyncWarningThresholdMS is applied on each getChannel().force() - also needed on entire commit

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213971#comment-16213971
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2921 at 10/21/17 3:34 PM:
-

Hi [~randgalt] and [~phunt] 

{quote}
That said having such a warning when request latency exceeds some threshold 
would also be useful.
{quote}

Isn't that what ZOOKEEPER-2770 is all about? Or I misunderstood this issue? 
There's a corresponding stale patch already: 
https://github.com/apache/zookeeper/pull/307

Wdyt? Please, let me know.

Cheers!



was (Author: eribeiro):
Hi [~randgalt] and [~phunt] :smile:

{quote}
That said having such a warning when request latency exceeds some threshold 
would also be useful.
{quote}

Isn't that what ZOOKEEPER-2770 is all about? Or I misunderstood this issue? 
There's a corresponding stale patch already: 
https://github.com/apache/zookeeper/pull/307

Wdyt? Please, let me know.

Cheers!


> fsyncWarningThresholdMS is applied on each getChannel().force() - also needed 
> on entire commit
> --
>
> Key: ZOOKEEPER-2921
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2921
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.3
>Reporter: Jordan Zimmerman
>Priority: Minor
>
> FileTxnLog.commit() has a warning when an individual sync takes longer than 
> {{fsyncWarningThresholdMS}}. However, it would also be useful to warn when 
> the entire commit operation takes longer than {{fsyncWarningThresholdMS}} as 
> this can cause client connection failures. Currently, commit() can take 
> longer than 2/3 of a session but still not log a warning.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2921) fsyncWarningThresholdMS is applied on each getChannel().force() - also needed on entire commit

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213971#comment-16213971
 ] 

Edward Ribeiro commented on ZOOKEEPER-2921:
---

Hi [~randgalt] and [~phunt] :smile:

{quote}
That said having such a warning when request latency exceeds some threshold 
would also be useful.
{quote}

Isn't that what ZOOKEEPER-2770 is all about? Or I misunderstood this issue? 
There's a corresponding stale patch already: 
https://github.com/apache/zookeeper/pull/307

Wdyt? Please, let me know.

Cheers!


> fsyncWarningThresholdMS is applied on each getChannel().force() - also needed 
> on entire commit
> --
>
> Key: ZOOKEEPER-2921
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2921
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.3
>Reporter: Jordan Zimmerman
>Priority: Minor
>
> FileTxnLog.commit() has a warning when an individual sync takes longer than 
> {{fsyncWarningThresholdMS}}. However, it would also be useful to warn when 
> the entire commit operation takes longer than {{fsyncWarningThresholdMS}} as 
> this can cause client connection failures. Currently, commit() can take 
> longer than 2/3 of a session but still not log a warning.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Let's cut a ZK 3.4.11 release

[Edward Ribeiro]

+1 about cutting a new release.

Edward

On Fri, Oct 13, 2017 at 4:39 PM, Patrick Hunt  wrote:
>
> Please note the subject line. I did that on purpose. ;-)
>
> That said I don't see why we couldn't have a 3.5.4-beta thereafter, the
> hanging issues (e.g. what Jordan mentioned) is one of the reasons why I
> planned to do 3.4 first.
>
> Regards,
>
> Patrick
>
> On Fri, Oct 13, 2017 at 11:40 AM, Jordan Zimmerman <
> jor...@jordanzimmerman.com> wrote:
>
> > I have 2 issues I'm really anxious to get in 3.4.5:
> >
> > https://github.com/apache/zookeeper/pull/378 <
> > https://github.com/apache/zookeeper/pull/378>
> >
> > https://github.com/apache/zookeeper/pull/332
> >
> > > On Oct 13, 2017, at 8:25 PM, Enrico Olivelli 
> > wrote:
> > >
> > > It would be great to have a 3.5.4 beta release, 3.5 branch is great
as it
> > > has SSL support, but is still lacks quorum peer auth.
> > >
> > > Thank you
> > > Enrico
> > >
> > > Il ven 13 ott 2017, 20:12 Abraham Fine  ha scritto:
> > >
> > >> Great idea, +1
> > >>
> > >> On Fri, Oct 13, 2017, at 11:11, Patrick Hunt wrote:
> > >>> Hi folks, any objection to cutting a 3.4.11 release? It's been
awhile
> > >>> since
> > >>> 3.4.10 and we have over 50 JIRA that have gone into the 3.4 branch.
> > >>>
> > >>> If there are no objections I'll start the process sometime next
week.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Patrick
> > >>
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> >
> >

[jira] [Commented] (ZOOKEEPER-2814) Ignore space after comma in connection string

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137354#comment-16137354
 ] 

Edward Ribeiro commented on ZOOKEEPER-2814:
---

Hi [~nikbhi15],

FYI, the trim of the host string seems to be fixed on branch-3.5 and master, 
doesn't it? See 
https://github.com/apache/zookeeper/blob/branch-3.5/src/java/main/org/apache/zookeeper/common/StringUtils.java#L37
 

While it is not fixed on branch-3.4 yet: 
https://github.com/apache/zookeeper/blob/branch-3.4/src/java/main/org/apache/zookeeper/client/ConnectStringParser.java#L65

I suggest that you add a method to check the host string with spaces after (and 
before) the comma.

> Ignore space after comma in connection string
> -
>
> Key: ZOOKEEPER-2814
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2814
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Viliam Durina
>Assignee: Nikhil Ashok Bhide
>Priority: Minor
>
> I'm using the following connection string:
> {{10.0.0.179:2181,10.0.0.176:2181}}
> However, I get:
> {{java.net.UnknownHostException: 10.0.0.176: Name or service not known
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at ...
> ...}}
> The problem was the space after the comma. I suggest to either make the space 
> optional or produce error on it, as this is a real pain to spot. Using the 
> space also makes the connect string more readable. Spaces are not allowed in 
> domain names.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2614) Port ZOOKEEPER-1576 to branch3.4

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103527#comment-16103527
 ] 

Edward Ribeiro commented on ZOOKEEPER-2614:
---

Hi Thomas, take a look at 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute on how to 
contribute via Github. I can take a look today yet or as soon as it is 
available.

> Port ZOOKEEPER-1576 to branch3.4
> 
>
> Key: ZOOKEEPER-2614
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2614
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.4.11
>
> Attachments: ZOOKEEPER-2614.branch-3.4.00.patch
>
>
> ZOOKEEPER-1576 handles UnknownHostException and it good to have this change 
> for 3.4 branch as well. Porting the changes to 3.4 after resolving the 
> conflicts



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072626#comment-16072626
 ] 

Edward Ribeiro commented on ZOOKEEPER-2591:
---

Cool, got it. It is the only edge case previously described and your solution 
is nice. Excuse me for disturbing the talk with a spurious example.

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>        Reporter: Edward Ribeiro
>    Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072579#comment-16072579
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2591 at 7/3/17 3:11 PM:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392

*So, even though the creation follows the same path, the container deletion has 
a different one.*

But I totally agree with you that this issue can not be worth working on, or 
could use something different from adding a checkACL. :)




was (Author: eribeiro):
[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392

**So, even though the creation follows the same path, the container deletion 
has a different one.**



> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>        Reporter: Edward Ribeiro
>    Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072579#comment-16072579
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2591 at 7/3/17 3:08 PM:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392

**So, even though the creation follows the same path, the container deletion 
has a different one.**




was (Author: eribeiro):
[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392



> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>        Reporter: Edward Ribeiro
>    Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072579#comment-16072579
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2591 at 7/3/17 3:06 PM:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392




was (Author: eribeiro):
[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed.

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>        Reporter: Edward Ribeiro
>    Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072579#comment-16072579
 ] 

Edward Ribeiro commented on ZOOKEEPER-2591:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed.

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>        Reporter: Edward Ribeiro
>    Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072530#comment-16072530
 ] 

Edward Ribeiro commented on ZOOKEEPER-2591:
---

[~randgalt], another edge case would be the following: a client create a 
container znode and populate it with children znodes. This client is the only 
in charge of deleting the children. Another clients should only be able to read 
the children znode contents, but a misbehaved client can delete children znodes 
in the container znode. With ACL properly set this other clients would not be 
able to delete the children of the master client. Does it make sense?

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>        Reporter: Edward Ribeiro
>    Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: New PMC Member: Michael Han

[Edward Ribeiro]

​Congrat
​ulations
​,
​Mic
​hael!
​
​Well d
​eserved
​!​
​
​
​
​
​
​
​


On Tue, Jun 27, 2017 at 2:07 PM, Patrick Hunt  wrote:

> Kudos Michael, well deserved!
>
> Patrick
>
> On Tue, Jun 27, 2017 at 9:49 AM, Jordan Zimmerman <
> jor...@jordanzimmerman.com> wrote:
>
> > Congrats!
> >
> > > On Jun 27, 2017, at 11:48 AM, Flavio Junqueira  wrote:
> > >
> > > I'm very happy to announce that the Apache ZooKeeper PMC has voted to
> > invite Michael Han to join the PMC and Michael accepted. Michael has done
> > outstanding work in the community over the recent past and we felt it was
> > time for Michael to deepen his level of engagement by joining the PMC.
> > >
> > > Please join me in congratulating Michael for his achievement.
> > Congratulations, Michael!
> > >
> > > -Flavio
> > >
> > >
> >
> >
>

[jira] [Commented] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15988614#comment-15988614
 ] 

Edward Ribeiro commented on ZOOKEEPER-2662:
---

Sure [~hanm], gonna port it to branch-3.5! :)

By the way, I saw that {{FileTxnSnapLogTest}}, that this patch uses, doesn't 
exist on branch-3.5. It was created as part of ZOOKEEPER-261 that both of us 
reviewed, but it got only committed on master. It was that on purpose [~breed]?

Best regards!

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>        Assignee: Edward Ribeiro
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15985814#comment-15985814
 ] 

Edward Ribeiro commented on ZOOKEEPER-2662:
---

Hey [~ckulkarni], I didn't have any spare cycle to spend on ZK issues, but got 
to resume it now. Thanks for bringing this up. Yup, I think this unit test is 
enough, so thank you **very much** for the test case. :)

[~hanm], would you mind to take a look at this PR, please?

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>        Assignee: Edward Ribeiro
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro updated ZOOKEEPER-2662:
--
Fix Version/s: 3.6.0

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>        Assignee: Edward Ribeiro
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Graceful close of ZooKeeper client

[Edward Ribeiro]

Yup, it sounds great. :)

PS: btw, congrats on new BK committer status.

Em 11 de abr de 2017 9:21 AM, "Enrico Olivelli" <eolive...@gmail.com>
escreveu:

2017-02-17 15:59 GMT+01:00 Edward Ribeiro <edward.ribe...@gmail.com>:

> Hey Enrico,
>
> I suggest you to get in touch with Jordan Zimmerman (here on the list) to
> make sure your proposed change doesn't break backwards compatibility.
> Jordan is creator of Curator, the best ZK lib out there, and an active
> member on this list.
>
>
Edward,

I'm back after some month running in production.
My final proposal is to leave the ZooKeeper#close method as it is
currently, because many times there is a need to fast close the ZK handle
without waiting.
I had some production cases in which in order to react to a session
expiration the clients needs to open a new ZK handle and tries to close the
previous one, but the delay introduced a lot of bugs.

I have introduced a new close(int maxWaitTime) which waits for the graceful
shutdown and it is very useful in two cases:
- webapps with reloading (so that the contextDestroyed callbacks need to
wait for a perfect cleanup of the env)
- unit tests cases (enables to run tests in a more predicatable way)

The new method will not introduce any compatibility issue, even with
Curator; maybe @Jordan can you confirm that ?

I can update the JIRA and submit a PR to share my patch, I really would
like to have this small feature in 3.5.x branch

Does it sound good to you ?





> Cheers,
> Eddie
>
> On Thu, Feb 16, 2017 at 2:14 PM, Enrico Olivelli <eolive...@gmail.com>
> wrote:
>
> > Hi ZooKeepers,
> > I have just created this and issue to improve client-side "close"
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2697 Handle graceful
> stop
> > of ZookKeeper client
> >
> > If the idea is acceptable for you I can write a patch and file a PR.
> >
> > Thanks
> > -- Enrico
> >
>

Re: Introduce ZooKeeper flaky test dashboard

[Edward Ribeiro]

Very cool feature! Congratulations for initiative! :D

Em 11 de abr de 2017 11:48 PM, "Jordan Zimmerman" <
jor...@jordanzimmerman.com> escreveu:

> Nice work - we could really use this on Curator. I'll be stealing this
> soon ;D
>
> > On Apr 11, 2017, at 9:33 PM, Michael Han  wrote:
> >
> > tl;dr
> > https://builds.apache.org/job/ZooKeeper-Find-Flaky-Tests/
> lastSuccessfulBuild/artifact/report.html
> >
> >
> > We all know quality is important to this project. One of major advantage
> of
> > ZooKeeper comparing to other similar solutions is its quality: solid,
> > stable, and well tested. Unit tests are playing an important role for
> ZK's
> > quality so we need take these tests seriously. In particular for failed
> > tests, it's easy to blame they are failed because of flaky but usually
> > there are bugs (sometimes very subtle ones) behind the failures.
> >
> > Inspired by some good work done on HBase project, I've borrowed and
> tweaked
> > their script so it applies to ZooKeeper project. The dashboard is now up
> > and a Jenkins job is running on a daily base to monitor our builds and
> pick
> > up flaky tests. I hope this dashboard can help increase the visibility
> and
> > raise awareness of the quality of unit tests, and also help developers
> > track and diagnose failures.
> >
> > Any feedback will be appreciated, and of course, contributions are very
> > welcome.
> >
> > --
> > Cheers
> > Michael.
>
>

Re: ZOOKEEPER-900

[Edward Ribeiro]

Hi Atri,

Comment on the issues themselves. It helps.

Regards,
Eddie

On Tue, Mar 28, 2017 at 1:33 AM, Atri Sharma  wrote:

> Hi Patrick,
>
> I am fine with either. I tried pinging the owners but got no response.
>
> Please let me know.
>
> Regards,
>
> Atri
>
> On Tue, Mar 28, 2017 at 4:51 AM, Patrick Hunt  wrote:
> > Hi Atri. Which do you intend to work on? 900, 901, or both? Typically if
> > someone is intending to work on something they will be listed as the
> > "assigned" in JIRA. They would be the first person to check in with. If
> > they no longer intend to work on something it's easy enough to reassign.
> >
> > Regards,
> >
> > Patrick
> >
> > On Sat, Mar 25, 2017 at 7:36 AM, Atri Sharma 
> wrote:
> >
> >> Hi folks,
> >>
> >> I was looking to work on ZOOKEEPER-901. Could anybody please let me
> >> know if they are working on it?
> >>
> >> --
> >> Regards,
> >>
> >> Atri
> >> l'apprenant
> >>
>
>
>
> --
> Regards,
>
> Atri
> l'apprenant
>

[jira] [Comment Edited] (ZOOKEEPER-2739) maxClientCnxns not working in NettyServerCnxnFactory

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941564#comment-15941564
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2739 at 3/25/17 4:34 AM:


Hi [~vincentpoon], I have created a new PR for ZOOKEEPER-2280 and rebased it to 
current master. It also applies to branch-3.5, btw. The jira issue has the 
updated link now.

There are two review comments by [~fpj] yet to be addressed (I commented on new 
PR) and further review/tests. Gonna do that next, so that we can get this patch 
in asap. Any comment on PR is welcome in the meantime. :)


was (Author: eribeiro):
Hi [~vincentpoon], I have created a new PR and rebased it to current master. It 
also applies to branch-3.5. There are two review comments by [~fpj] yet to be 
addressed (I commented on new PR) and further review/tests. Gonna do that next. 
Any comment on PR is welcome in the meantime. :)

> maxClientCnxns not working in NettyServerCnxnFactory
> 
>
> Key: ZOOKEEPER-2739
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2739
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.0, 3.6.0
>Reporter: Vincent Poon
> Attachments: MaxNettyCnxnsTest.patch
>
>
> The maxClientCnxns field isn't being used in NettyServerCnxnFactory, and 
> therefore the connection limit isn't observed.
> See attached test



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2739) maxClientCnxns not working in NettyServerCnxnFactory

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941564#comment-15941564
 ] 

Edward Ribeiro commented on ZOOKEEPER-2739:
---

Hi [~vincentpoon], I have created a new PR and rebased it to current master. It 
also applies to branch-3.5. There are two review comments by [~fpj] yet to be 
addressed (I commented on new PR) and further review/tests. Gonna do that next. 
Any comment on PR is welcome in the meantime. :)

> maxClientCnxns not working in NettyServerCnxnFactory
> 
>
> Key: ZOOKEEPER-2739
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2739
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.0, 3.6.0
>Reporter: Vincent Poon
> Attachments: MaxNettyCnxnsTest.patch
>
>
> The maxClientCnxns field isn't being used in NettyServerCnxnFactory, and 
> therefore the connection limit isn't observed.
> See attached test



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941510#comment-15941510
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2659 at 3/25/17 2:49 AM:


Hey [~praste],

I am no committer, but I see that you have invested *a lot* of work on this. 
This has been the subject of a previous and unfinished JIRA issue, 
ZOOKEEPER-2342, so definitely there is an interest on this matter. Wouldn't you 
like to reopen this jira issue and the PR you made, so that others in the 
community can take a look?

I will take the liberty to ping some ZK committers -- [~arshadmohammad], 
[~hanm] so that they can take a look when/if they have a spare cycles. I hope 
you don't mind guys! I know you are pretty busy, but migrating to newer 
versions of log4j is a must have for future ZK versions, imo.

Cheers!



was (Author: eribeiro):
Hey [~praste],

I am no committer, but I see that you have invested *a lot* of work on this. 
This has been the subject of a previous and unfinished JIRA issue, 
ZOOKEEPER-2342, so definitely there is an interest on this matter. Wouldn't you 
like to reopen the PR you made, so that others in the community can take a look?

I will take the liberty to ping some ZK committers -- [~arshadmohammad], 
[~hanm] so that they can take a look when/if they have a spare cycles. I hope 
you don't mind guys! I know you are pretty busy, but migrating to newer 
versions of log4j is a must have for future ZK versions, imo.

Cheers!


> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Assignee: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941510#comment-15941510
 ] 

Edward Ribeiro commented on ZOOKEEPER-2659:
---

Hey [~praste],

I am no committer, but I see that you have invested *a lot* of work on this. 
This has been the subject of a previous and unfinished JIRA issue, 
ZOOKEEPER-2342, so definitely there is an interest on this matter. Wouldn't you 
like to reopen the PR you made, so that others in the community can take a look?

I will take the liberty to ping some ZK committers -- [~arshadmohammad], 
[~hanm] so that they can take a look when/if they have a spare cycles. I hope 
you don't mind guys! I know you are pretty busy, but migrating to newer 
versions of log4j is a must have for future ZK versions, imo.

Cheers!


> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Assignee: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2739) maxClientCnxns not working in NettyServerCnxnFactory

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941485#comment-15941485
 ] 

Edward Ribeiro commented on ZOOKEEPER-2739:
---

Hi [~vincentpoon],

I started working on this exact same issue long before, but got side tracked by 
other commitments. Let's chat! ;)

> maxClientCnxns not working in NettyServerCnxnFactory
> 
>
> Key: ZOOKEEPER-2739
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2739
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.0, 3.6.0
>Reporter: Vincent Poon
> Attachments: MaxNettyCnxnsTest.patch
>
>
> The maxClientCnxns field isn't being used in NettyServerCnxnFactory, and 
> therefore the connection limit isn't observed.
> See attached test



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Make 3.5.3 the first beta release.

[Edward Ribeiro]

+1 non binding

On Thu, Mar 23, 2017 at 2:17 PM, Rakesh Radhakrishnan 
wrote:

> +1
>
>
> Rakesh
>
> On Thu, Mar 23, 2017 at 10:41 PM, Jordan Zimmerman <
> jor...@jordanzimmerman.com> wrote:
>
> > +1 non binding
> >
> > 
> > Jordan Zimmerman
> >
> > > On Mar 23, 2017, at 11:50 AM, Michael Han  wrote:
> > >
> > > Hi,
> > >
> > > As previously discussed on dev list [1] and JIRA [2], I propose we make
> > the
> > > upcoming 3.5.3 release the first beta release and drops the alpha tag.
> > >
> > > Please vote by *March 27th 2017, 23:59 UTC+0*. If no objections, I'll
> > > commit the patch for [2] and proceed with release process next week
> after
> > > the vote cycle ends.
> > >
> > > [1] 3.5.3: alpha or beta?
> > >  > 201703.mbox/%3CCA%2Bi0x1JZacVMQGd_Jb34jSaw7p_nhWpcx9uzHwCwPPF%2BPPrf3g%
> > 40mail.gmail.com%3E>
> > > [2] ZOOKEEPER-2734  jira/browse/ZOOKEEPER-2734
> > >
> > >
> > > --
> > > Cheers
> > > Michael.
> >
>

[jira] [Comment Edited] (ZOOKEEPER-2736) Add a connection rate limiter

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939052#comment-15939052
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2736 at 3/23/17 7:56 PM:


Hey, [~vincentpoon], nice initiative!

I remember some past discussion about introducing a rate limiter into ZK 
codebase, particularly in the context of ZOOKEEPER-2693, so you may have to 
take a look there first to see what the others contributors have in mind. Also, 
*and most important*, we are not using patch upload + review board to accept 
patches in ZooKeeper anymore. Please, open a PR on Github as specified here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards

PS: I was unable to apply your patch to branch-3.4 and branch-3.5. :( Did you 
generate your patch with a {{git diff --no-prefix}} or equivalent? 


was (Author: eribeiro):
Hey, [~vincentpoon], nice initiative!

I remember some past discussion about introducing a rate limiter into ZK 
codebase, particularly in the context of ZOOKEEPER-2693, so you may have to 
take a look there first to see what the others contributors have in mind. Also, 
*and most important*, we are not using patch upload + review board to accept 
patches in ZooKeeper anymore. Please, open a PR on Github as specified here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards

> Add a connection rate limiter
> -
>
> Key: ZOOKEEPER-2736
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2736
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Vincent Poon
> Attachments: ZOOKEEPER-2736.v1.patch
>
>
> Currently the maxClientCnxns property only limits the aggregate number of 
> connections from a client, but not the rate at which connections can be 
> created.
> This patch adds a configurable connection rate limiter which limits the rate 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2736) Add a connection rate limiter

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939052#comment-15939052
 ] 

Edward Ribeiro commented on ZOOKEEPER-2736:
---

Hey, [~vincentpoon], nice initiative!

I remember some past discussion about introducing a rate limiter into ZK 
codebase, particularly in the context of ZOOKEEPER-2693, so you may have to 
take a look there first to see what the others contributors have in mind. Also, 
*and most important*, we are not using patch upload + review board to accept 
patches in ZooKeeper anymore. Please, open a PR on Github as specified here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards

> Add a connection rate limiter
> -
>
> Key: ZOOKEEPER-2736
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2736
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Vincent Poon
> Attachments: ZOOKEEPER-2736.v1.patch
>
>
> Currently the maxClientCnxns property only limits the aggregate number of 
> connections from a client, but not the rate at which connections can be 
> created.
> This patch adds a configurable connection rate limiter which limits the rate 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: github merging?

[Edward Ribeiro]

Hi, it looks like an error on setuptools:
http://stackoverflow.com/questions/41827464/pythong-pycparser-setup-error
 (the lib is different but the error is the same on lines)

Eddie

On Thu, Mar 16, 2017 at 1:58 PM, Camille Fournier 
wrote:

> Thanks Michael I'll check and see if upgrading to 2.7.11 fixes it
>
> On Thu, Mar 16, 2017 at 12:26 PM, Michael Han  wrote:
>
> > Looks like a python environment issue. What python version and
> installation
> > are you using? I am using python 2.7.11 installed via homebrew for
> > reference. Also make sure pip is installed (sudo easy_install pip).
> >
> > On Thu, Mar 16, 2017 at 8:48 AM, Camille Fournier 
> > wrote:
> >
> > > Also, can we get this in the 3.5 branch as well?
> > >
> > > On Thu, Mar 16, 2017 at 11:03 AM, Camille Fournier  >
> > > wrote:
> > >
> > > > I'm trying to follow the instructions on the wiki to approve changes:
> > > > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > > Merging+Github+Pull+Requests
> > > >
> > > > but it does not appear to work. Specifically, this merge script:
> > > > python zk-merge-pr.py
> > > >
> > > > is erroring out with:
> > > >
> > > >   File "/Library/Python/2.7/site-packages/pbr-2.0.0-py2.7.egg/
> > > pbr/version.py",
> > > > line 25, in 
> > > >
> > > > import pkg_resources
> > > >
> > > >   File "build/bdist.macosx-10.12-intel/egg/pkg_resources/__
> init__.py",
> > > > line 72, in 
> > > >
> > > >   File "build/bdist.macosx-10.12-intel/egg/packaging/
> requirements.py",
> > > > line 59, in 
> > > >
> > > > TypeError: __call__() takes exactly 2 arguments (1 given)
> > > >
> > > >
> > > > Any ideas?
> > > >
> > > >
> > > > C
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>

[jira] [Commented] (ZOOKEEPER-2705) Container node remains indefinitely after session has long expired!

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882972#comment-15882972
 ] 

Edward Ribeiro commented on ZOOKEEPER-2705:
---

I am afraid there's no timeline yet. But you can follow and engange on the 
undergoing discussion about 3.5.x release at zookeeper-user mailing list thread 
below.

http://zookeeper-user.578899.n2.nabble.com/Query-3-5-x-version-as-alpha-td7582952.html

Cheers!

> Container node remains indefinitely after session has long expired!
> ---
>
> Key: ZOOKEEPER-2705
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2705
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.5.1
> Environment: 5 x RHEL 2.6.32-431.29.2.el6.x86_64
>Reporter: Steve Fitzgerald
>
> Zookeeper version: 3.5.1-alpha
> Curator Framework version: 3.2.0
> We have a 5 node cluster. When we register a service instance everything is 
> created within zookeeper successfully, e.g. for a service names 
> "fake-test-service" I can see the following created:
> 1. /api/enablement/fake-test-service
> 2. /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5
> When I abnormally kill (kill -9) the process that the service is registered 
> from I expect both of the above to get removed by zookeeper when it expires 
> the session. But only 
> /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5 gets 
> removed successfully.
> Here is a snippet of the log file:
> {noformat}
> 2017-02-23 05:50:00,977 [myid:5] - TRACE 
> [SessionTracker:SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:ZooKeeperServer@384][] - Expiring session 0x502dbce4df6, 
> timeout of 4ms exceeded
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:QuorumZooKeeperServer@132][] - Submitting global closeSession 
> request for session 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::ZooTrace@90][] - :Psessionid:0x502dbce4df6 type:closeSession 
> cxid:0x0 zxid:0xfffe txntype:unknown reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - INFO  [ProcessThread(sid:5 
> cport:-1)::PrepRequestProcessor@649][] - Processed session termination for 
> sessionid: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::CommitProcessor@340][] - Processing request:: 
> sessionid:0x502dbce4df6 type:closeSession cxid:0x0 zxid:0x1d0003 
> txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::Leader@1066][] - Proposing:: sessionid:0x502dbce4df6 
> type:closeSession cxid:0x0 zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@787][] - Ack 
> zxid: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@790][] - 
> outstanding proposal: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@793][] - 
> outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.161:55588:CommitProcessor@327][] - Committing 
> request:: sessionid:0x502dbce4df6 type:closeSession cxid:0x0 
> zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,983 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.162:475

[jira] [Commented] (ZOOKEEPER-2705) Container node remains indefinitely after session has long expired!

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880700#comment-15880700
 ] 

Edward Ribeiro commented on ZOOKEEPER-2705:
---

Hi [~stondofitz], 

Looks like you hit https://issues.apache.org/jira/browse/ZOOKEEPER-2464 that 
was recently fixed by https://issues.apache.org/jira/browse/ZOOKEEPER-2680 

TL;DR: {{DataNode.getChildren()}} could either return an empty collection or 
null, and this broke ContainerManager at line 151, as shown in your log.

Could you confirm it is the same issue, please?

> Container node remains indefinitely after session has long expired!
> ---
>
> Key: ZOOKEEPER-2705
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2705
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.5.1
> Environment: 5 x RHEL 2.6.32-431.29.2.el6.x86_64
>Reporter: Steve Fitzgerald
>
> Zookeeper version: 3.5.1-alpha
> Curator Framework version: 3.2.0
> We have a 5 node cluster. When we register a service instance everything is 
> created within zookeeper successfully, e.g. for a service names 
> "fake-test-service" I can see the following created:
> 1. /api/enablement/fake-test-service
> 2. /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5
> When I abnormally kill (kill -9) the process that the service is registered 
> from I expect both of the above to get removed by zookeeper when it expires 
> the session. But only 
> /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5 gets 
> removed successfully.
> Here is a snippet of the log file:
> {noformat}
> 2017-02-23 05:50:00,977 [myid:5] - TRACE 
> [SessionTracker:SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:ZooKeeperServer@384][] - Expiring session 0x502dbce4df6, 
> timeout of 4ms exceeded
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:QuorumZooKeeperServer@132][] - Submitting global closeSession 
> request for session 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::ZooTrace@90][] - :Psessionid:0x502dbce4df6 type:closeSession 
> cxid:0x0 zxid:0xfffe txntype:unknown reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - INFO  [ProcessThread(sid:5 
> cport:-1)::PrepRequestProcessor@649][] - Processed session termination for 
> sessionid: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::CommitProcessor@340][] - Processing request:: 
> sessionid:0x502dbce4df6 type:closeSession cxid:0x0 zxid:0x1d0003 
> txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::Leader@1066][] - Proposing:: sessionid:0x502dbce4df6 
> type:closeSession cxid:0x0 zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@787][] - Ack 
> zxid: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@790][] - 
> outstanding proposal: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@793][] - 
> outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.161:55588:CommitProcessor@327][] - Committing 
> request:: sessionid:0x502dbce4df6 type:closeSession cxid:0x0 
> zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@793

[jira] [Commented] (ZOOKEEPER-2700) Force ZooKeeper to generate snapshot

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871945#comment-15871945
 ] 

Edward Ribeiro commented on ZOOKEEPER-2700:
---

Hi [~flier],

Some observations: 

1) this issue is a duplicate of ZOOKEEPER-1729 so I am marking it as such.

2) based on discussions on ZOOKEEPER-1729 (please, read it) and the security 
problems related on ZOOKEEPER-2693, implementing this command as a 4lw is a big 
*NO*. I think it could be be implemented as a JMX command and/or a ServerAdmin 
command tough.

Additional comments I will post on the GH review comment.

Cheers!

> Force ZooKeeper to generate snapshot
> 
>
> Key: ZOOKEEPER-2700
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2700
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Flier Lu
>Priority: Minor
>
> When cold backup or remote offline sync Zookeeper instances, we need the 
> latest snapshot.
> Add a four letter `snap` command to force Zookeeper to generate snapshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2700) Force ZooKeeper to generate snapshot

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871945#comment-15871945
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2700 at 2/17/17 3:07 PM:


Hi [~flier],

Some observations: 

1) this issue is a duplicate of ZOOKEEPER-1729 so I am marking it as such.

2) based on discussions on ZOOKEEPER-1729 (please, read it) and the security 
problems related on ZOOKEEPER-2693, implementing this command as a 4lw is a big 
*NO*. I think it could be be implemented as a JMX command and/or a ServerAdmin 
command tough.

3) Where are your unit tests? :) 

Additional comments I will post on the GH review comment.

Cheers!


was (Author: eribeiro):
Hi [~flier],

Some observations: 

1) this issue is a duplicate of ZOOKEEPER-1729 so I am marking it as such.

2) based on discussions on ZOOKEEPER-1729 (please, read it) and the security 
problems related on ZOOKEEPER-2693, implementing this command as a 4lw is a big 
*NO*. I think it could be be implemented as a JMX command and/or a ServerAdmin 
command tough.

Additional comments I will post on the GH review comment.

Cheers!

> Force ZooKeeper to generate snapshot
> 
>
> Key: ZOOKEEPER-2700
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2700
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Flier Lu
>Priority: Minor
>
> When cold backup or remote offline sync Zookeeper instances, we need the 
> latest snapshot.
> Add a four letter `snap` command to force Zookeeper to generate snapshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Graceful close of ZooKeeper client

[Edward Ribeiro]

Hey Enrico,

I suggest you to get in touch with Jordan Zimmerman (here on the list) to
make sure your proposed change doesn't break backwards compatibility.
Jordan is creator of Curator, the best ZK lib out there, and an active
member on this list.

Cheers,
Eddie

On Thu, Feb 16, 2017 at 2:14 PM, Enrico Olivelli 
wrote:

> Hi ZooKeepers,
> I have just created this and issue to improve client-side "close"
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2697 Handle graceful stop
> of ZookKeeper client
>
> If the idea is acceptable for you I can write a patch and file a PR.
>
> Thanks
> -- Enrico
>

[jira] [Comment Edited] (ZOOKEEPER-2688) rmr leads to "Node does not exist"

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859552#comment-15859552
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2688 at 2/9/17 2:03 PM:
---

Hi [~ror6ax], 

The {{rmr}} calls a utility method to recursively delete a root znode and its 
children. This method operates in two steps: a) first it traverses the tree 
from the root path and stores the absolute paths for root and children in a 
list. b) then it traverses the list, calling ZK delete method for each absolute 
path.

Based on the znode path you posted only, I *guess* that is happening a *race 
condition* as below:

0. Suppose that {{/vault}} has a lot of children znodes, many levels deep (this 
is not really necessary if the actions interleaving is just precise).

1. Also, *suppose*  
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} is an 
ephemeral node (it has the word "lock" in its path, so I think it's been used 
for distributed locking). The session that owns this ephemeral node has been 
closed, then znode will be removed;

2. The tree traversal method I cited above gets 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} and 
adds the path to the list *just before* it has been removed (miliseconds 
before).

3. ZK deletes 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}};

4. the list of paths to be delete is traversed (remember: a long list) and 
*eventually* reaches 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} but 
when it try to delete it there is an exception because it has already been 
deleted by ZK itself;

Does it make sense?

Please, it's just my theory for what is happening.

PS: Even though {{rmr}} is being deprecated in favor of {{deleteAll}}, it also 
uses the same utility class so this behavior could potentially happen with with 
{{deleteAll}}.

*OTOH*, it can indeed be some sort of inconsistency. Did you try to issue a ls 
or get command on 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} 
*after the error* to see if it really exists? Or try to remove it via delete?


was (Author: eribeiro):
Hi [~ror6ax], 

The rmr calls a utility method to recursively delete a root znode and its 
children. This method operates in two steps: a) first it traverses the tree 
from the root path and stores the absolute paths for root and children in a 
list. b) it traverses the list and calling ZK delete method for each path.

Based on the znode path you posted only, I *guess* that is happening a race 
condition as below:

0. Suppose that {{/vault}} is has a lot of children znodes, many levels deep.

1. Also, *suppose*  
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} is an 
ephemeral node (it has the word "lock" in its path, so it's been used for 
distributed locking). The session that owns this ephemeral node has been 
closed, then znode will be removed;

2. The tree traversal method I cited above gets 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} and 
adds the path to the list *just before* it has been removed (miliseconds 
before).

3. ZK deletes 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}};

4. the list of paths to be delete is traversed (remember: a long list) and 
*eventually* reaches 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} but 
when it try to delete it there is an exception because it has already been 
deleted by ZK itself;

Does it make sense?

Please, it's just my theory for what is happening.

PS: Even though {{rmr}} is being deprecated in favor of {{deleteAll}}, it also 
uses the same utility class so this behavior could potentially happen with with 
{{deleteAll}}.

*OTOH*, it can indeed be some sort of inconsistency. Did you try to issue a ls 
or get command on 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} 
*after the error* to see if it really exists? Or try to remove it via delete?

> rmr leads to "Node does not exist"
> --
>
> Key: ZOOKEEPER-2688
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2688
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Gregory Reshetniak
>
> Issuing rmr /vault leads to Node does not exist: 
> /vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28
> I know that rmr is getting deprecated in next version, but I think this might 
> be cluster consistency bug.
> Please advice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2688) rmr leads to "Node does not exist"

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859552#comment-15859552
 ] 

Edward Ribeiro commented on ZOOKEEPER-2688:
---

Hi [~ror6ax], 

The rmr calls a utility method to recursively delete a root znode and its 
children. This method operates in two steps: a) first it traverses the tree 
from the root path and stores the absolute paths for root and children in a 
list. b) it traverses the list and calling ZK delete method for each path.

Based on the znode path you posted only, I *guess* that is happening a race 
condition as below:

0. Suppose that {{/vault}} is has a lot of children znodes, many levels deep.

1. Also, *suppose*  
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} is an 
ephemeral node (it has the word "lock" in its path, so it's been used for 
distributed locking). The session that owns this ephemeral node has been 
closed, then znode will be removed;

2. The tree traversal method I cited above gets 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} and 
adds the path to the list *just before* it has been removed (miliseconds 
before).

3. ZK deletes 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}};

4. the list of paths to be delete is traversed (remember: a long list) and 
*eventually* reaches 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} but 
when it try to delete it there is an exception because it has already been 
deleted by ZK itself;

Does it make sense?

Please, it's just my theory for what is happening.

PS: Even though {{rmr}} is being deprecated in favor of {{deleteAll}}, it also 
uses the same utility class so this behavior could potentially happen with with 
{{deleteAll}}.

*OTOH*, it can indeed be some sort of inconsistency. Did you try to issue a ls 
or get command on 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} 
*after the error* to see if it really exists? Or try to remove it via delete?

> rmr leads to "Node does not exist"
> --
>
> Key: ZOOKEEPER-2688
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2688
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Gregory Reshetniak
>
> Issuing rmr /vault leads to Node does not exist: 
> /vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28
> I know that rmr is getting deprecated in next version, but I think this might 
> be cluster consistency bug.
> Please advice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2665) Port QA github pull request build to branch 3.4 and 3.5

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859301#comment-15859301
 ] 

Edward Ribeiro commented on ZOOKEEPER-2665:
---

I am not a committer myself, but pinging [~hanm] & [~fpj] ;) 

> Port QA github pull request build to branch 3.4 and 3.5
> ---
>
> Key: ZOOKEEPER-2665
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2665
> Project: ZooKeeper
>  Issue Type: Test
>  Components: build
>Reporter: Flavio Junqueira
> Fix For: 3.5.3, 3.4.11
>
>
> We have QA build for pull requests against master but not against branches 
> 3.4 and 3.5. We need to port the necessary wiring to do it, it shouldn't be 
> difficult.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2672) Remove CHANGE.txt

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859287#comment-15859287
 ] 

Edward Ribeiro commented on ZOOKEEPER-2672:
---

[~rakeshr], Yup, I have been following the discussions and totally agree with 
you. :) No more questions by me. 

> Remove CHANGE.txt
> -
>
> Key: ZOOKEEPER-2672
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2672
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
>Assignee: Michael Han
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> The CHANGE.txt is already not the source of truth of what's changed after we 
> migrating to git - most of the git commits in recent couple of months don't 
> update CHANGE.txt. The option of updating CHANGE.txt during commit flow 
> automatically is none trivial, and do that manually is cumbersome and error 
> prone.
> The consensus is we would rely on source control revision logs instead of 
> CHANGE.txt moving forward; see 
> https://www.mail-archive.com/dev@zookeeper.apache.org/msg37108.html for more 
> details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859285#comment-15859285
 ] 

Edward Ribeiro commented on ZOOKEEPER-2662:
---

Ops, sorry for delaying this issue, gonna resume asap. Any feedback is welcome. 
:) 

Thanks!

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>        Assignee: Edward Ribeiro
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2665) Port QA github pull request build to branch 3.4 and 3.5

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859276#comment-15859276
 ] 

Edward Ribeiro commented on ZOOKEEPER-2665:
---

Hey [~eolivelli], thanks for stepping up. You can assign the issue to yourself, 
btw. I will provide the best support I can do. :)

Cheers,
Eddie

> Port QA github pull request build to branch 3.4 and 3.5
> ---
>
> Key: ZOOKEEPER-2665
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2665
> Project: ZooKeeper
>  Issue Type: Test
>  Components: build
>Reporter: Flavio Junqueira
> Fix For: 3.5.3, 3.4.11
>
>
> We have QA build for pull requests against master but not against branches 
> 3.4 and 3.5. We need to port the necessary wiring to do it, it shouldn't be 
> difficult.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2680) Correct DataNode.getChildren() inconsistent behaviour.

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15858205#comment-15858205
 ] 

Edward Ribeiro commented on ZOOKEEPER-2680:
---

The "Unsupported major.minor version 51.0" usually happens 'cause the code was 
compiled with a higher version JDK and run on a lower version JRE. In this 
particular case, looks like {{org/apache/kerby/kerberos/kerb}} was compiled on 
JDK7 and run on JRE6. Further info:

http://stackoverflow.com/questions/10382929/how-to-fix-java-lang-unsupportedclassversionerror-unsupported-major-minor-versi

http://stackoverflow.com/questions/20690143/java-unsupported-major-minor-version-51-0





> Correct DataNode.getChildren() inconsistent behaviour.
> --
>
> Key: ZOOKEEPER-2680
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2680
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.9, 3.5.1
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2680-01.patch
>
>
> DataNode.getChildren() API returns null and empty set if there are no 
> children in it depending on when the API is called. DataNode.getChildren() 
> API behavior should be changed and it should always return empty set if the 
> node does not have any child
> *DataNode.getChildren() API Current Behavior:*
> # returns null initially
> When DataNode is created and no children are added yet, 
> DataNode.getChildren() returns null
> # returns empty set after all the children are deleted:
> created a Node
> add a child
> delete the child
> DataNode.getChildren() returns empty set.
> After fix DataNode.getChildren() should return empty set in all the above 
> cases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: ZooKeeper 3.4.10 release discussion

[Edward Ribeiro]

Hi all,

Any chance of us getting ZOOKEEPER-2184 and ZOOKEEPER-2680 into 3.4.10
release?

IMHO, those look in good shape and would benefit from a final commit review.

Thanks,
Eddie

On Thu, Feb 2, 2017 at 2:13 PM, Rakesh Radhakrishnan <rake...@apache.org>
wrote:

> Hi All,
>
> I've tried an attempt by converting all the applicable svn commands to git
> commands in "HowToRelease using git" cwiki page. Welcome comments, thanks!
>
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> HowToRelease+using+git
>
> Thanks,
> Rakesh
>
> On Fri, Jan 27, 2017 at 11:54 PM, Edward Ribeiro <edward.ribe...@gmail.com
> >
> wrote:
>
> > ​​
> > Hi Rakesh,
> >
> > I have comment on ZK-2622.
> >
> > Took a look at the 'HowToRelease' using git page and have one minor
> > comment:
> >
> > 2. "If not already done, merge desired patches from master into the
> branch
> > and commit these changes.
> > (...)
> > "
> >
> > AFAIK merging from master to branch-3.4 would bring all those changes in
> > master and try to apply them to branch-3.4. This usuallys leads to lots
> of
> > conflicts and is not desirable. What I usually see in Cassandra commit
> > history is merging upwards: 2.2 -> 3.0 -> 3.1 -> master so that changes
> in
> > previous versions are
> > ​ported​ to
> >  further releases
> > ​: https://github.com/apache/cassandra/commits/trunk​
> >
> >
> > So
> > ​,​
> > I would rephrase the "merge desired patches from master into branch and
> > commit those changes" to "cherry-pick desired commits from master into
> > branch". The act of merging/rebasing/cherry-picking auto commit the
> > changes
> > on the target branch. If you want to avoid doing that then have to resort
> > to things like this:
> > http://stackoverflow.com/questions/8640887/git-merge-without-auto-commit
> >
> > BUT I AM NOT GIT EXPERT, so I feel free to ignore this suggestion.
> > ​Further info​
> >  here:
> > http://stackoverflow.com/questions/1241720/git-cherry-
> > pick-vs-merge-workflow
> >
> > ​Best regards,
> > Eddie​
> >
> >
> > On Fri, Jan 27, 2017 at 9:30 AM, Rakesh Radhakrishnan <
> rake...@apache.org>
> > wrote:
> >
> > > Thanks Edward for the interest. I hope you are watching 'HowToRelease'
> > > using git page discussion, which is still in progress. I'd like to give
> > > some more time to the folks to push their interesting issues(I'd prefer
> > > issues with low risk) until the release procedure is finalized.
> > >
> > > I've marked ZOOKEEPER-2622's fix version to 3.4.10, appreciate your
> > > feedback on the attached pull request so that some of our committers
> will
> > > help in pushing it upstream.
> > >
> > > Thanks,
> > > Rakesh
> > >
> > > On Thu, Jan 26, 2017 at 5:35 PM, Edward Ribeiro <
> > edward.ribe...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Rakesh and Flavio, what do you think about merging ZOOKEEPER-2622 to
> > > > branch-3.4 and include it in 3.4.10 besides branch-3.5 and master?
> > > >
> > > > Edward
> > > >
> > > > On Thu, Jan 26, 2017 at 8:20 AM, Flavio Junqueira <f...@apache.org>
> > > wrote:
> > > >
> > > > > Here are a few comments on the proposal of changes to the release
> > > > process:
> > > > >
> > > > > - It might be a better idea to preserve the HowToRelease document
> for
> > > > > future reference, clone the document, and change the cloned
> document
> > to
> > > > > reflect the git commands rather than svn.
> > > > > - We still need to modify Step 2 to be git oriented, otherwise it
> > will
> > > > > look odd that we have svn there.
> > > > > - In Step 4, I thought that we had informally agreed to rely on the
> > git
> > > > > log rather than maintain the CHANGES.txt file. If we aren't all
> > onboard
> > > > > with the idea of stopping to use CHANGES.txt, then we need to
> discuss
> > > > this
> > > > > separately.
> > > > > - Steps 5 and 6: I'm not sure why the steps to produce the release
> > > notes
> > > > > changes. We still resolve issues on jira which is pretty much the
> > > source
> > > > of
> > > > > data for the release notes

[jira] (ZOOKEEPER-2673) projet

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro resolved ZOOKEEPER-2673.
---
Resolution: Invalid

As this issue has been open a week ago without any description or a relevant 
title, I am closing it. [~salem-faraxen], let me know if you want to reopen and 
edit it to include any real issue.

> projet
> --
>
> Key: ZOOKEEPER-2673
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2673
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (ZOOKEEPER-2674) Projet-Final

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro resolved ZOOKEEPER-2674.
---
Resolution: Invalid

As this issue has been open a week ago without any description or a relevant 
title, I am closing it. [~salem-faraxen], let me know if you want to reopen and 
edit it to include any real issue.

> Projet-Final
> 
>
> Key: ZOOKEEPER-2674
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2674
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: ZooKeeper 3.4.10 release discussion

[Edward Ribeiro]

​​
Hi Rakesh,

I have comment on ZK-2622.

Took a look at the 'HowToRelease' using git page and have one minor comment:

2. "If not already done, merge desired patches from master into the branch
and commit these changes.
(...)
"

AFAIK merging from master to branch-3.4 would bring all those changes in
master and try to apply them to branch-3.4. This usuallys leads to lots of
conflicts and is not desirable. What I usually see in Cassandra commit
history is merging upwards: 2.2 -> 3.0 -> 3.1 -> master so that changes in
previous versions are
​ported​ to
 further releases
​: https://github.com/apache/cassandra/commits/trunk​


So
​,​
I would rephrase the "merge desired patches from master into branch and
commit those changes" to "cherry-pick desired commits from master into
branch". The act of merging/rebasing/cherry-picking auto commit the changes
on the target branch. If you want to avoid doing that then have to resort
to things like this:
http://stackoverflow.com/questions/8640887/git-merge-without-auto-commit

BUT I AM NOT GIT EXPERT, so I feel free to ignore this suggestion.
​Further info​
 here:
http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow

​Best regards,
Eddie​


On Fri, Jan 27, 2017 at 9:30 AM, Rakesh Radhakrishnan <rake...@apache.org>
wrote:

> Thanks Edward for the interest. I hope you are watching 'HowToRelease'
> using git page discussion, which is still in progress. I'd like to give
> some more time to the folks to push their interesting issues(I'd prefer
> issues with low risk) until the release procedure is finalized.
>
> I've marked ZOOKEEPER-2622's fix version to 3.4.10, appreciate your
> feedback on the attached pull request so that some of our committers will
> help in pushing it upstream.
>
> Thanks,
> Rakesh
>
> On Thu, Jan 26, 2017 at 5:35 PM, Edward Ribeiro <edward.ribe...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Rakesh and Flavio, what do you think about merging ZOOKEEPER-2622 to
> > branch-3.4 and include it in 3.4.10 besides branch-3.5 and master?
> >
> > Edward
> >
> > On Thu, Jan 26, 2017 at 8:20 AM, Flavio Junqueira <f...@apache.org>
> wrote:
> >
> > > Here are a few comments on the proposal of changes to the release
> > process:
> > >
> > > - It might be a better idea to preserve the HowToRelease document for
> > > future reference, clone the document, and change the cloned document to
> > > reflect the git commands rather than svn.
> > > - We still need to modify Step 2 to be git oriented, otherwise it will
> > > look odd that we have svn there.
> > > - In Step 4, I thought that we had informally agreed to rely on the git
> > > log rather than maintain the CHANGES.txt file. If we aren't all onboard
> > > with the idea of stopping to use CHANGES.txt, then we need to discuss
> > this
> > > separately.
> > > - Steps 5 and 6: I'm not sure why the steps to produce the release
> notes
> > > changes. We still resolve issues on jira which is pretty much the
> source
> > of
> > > data for the release notes.
> > > - Step 10: I personally don't like using "git commit -a" unless you're
> > > pretty sure that it is what you want. A much safer approach is to run
> > "git
> > > status" and "git add" to the individual files/directories.
> > > - Step 11: Why are we tagging with -s? Is that standard practice in
> other
> > > projects?
> > >
> > > -Flavio
> > >
> > > > On 26 Jan 2017, at 03:30, Rakesh Radhakrishnan <rake...@apache.org>
> > > wrote:
> > > >
> > > > Agreed, will try to resolve ZK-2184. I have included this to 3.4.10
> > > > releasing. I could see few open review comments in the PR, probably
> > will
> > > > push once this is concluded.
> > > >
> > > > Thanks,
> > > > Rakesh
> > > >
> > > > On Thu, Jan 26, 2017 at 2:01 AM, Flavio Junqueira <f...@apache.org>
> > > wrote:
> > > >
> > > >> I'd like to have ZK-2184 in as well. I have seen many cases in which
> > > >> applications are affected by that problem. If folks can help me push
> > it
> > > >> through, I'd appreciate.
> > > >>
> > > >> -Flavio
> > > >>
> > > >>> On 25 Jan 2017, at 17:01, Rakesh Radhakrishnan <rake...@apache.org
> >
> > > >> wrote:
> > > >>>
> > > >>> I've reviewed ZOOKEEPER-2044 pull request and added few comments. I
>

[jira] [Commented] (ZOOKEEPER-2494) reword documentation to say "a simple shell to execute file-like operations" instead of "a shell in which to execute simple file-system-like operations"

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15843158#comment-15843158
 ] 

Edward Ribeiro commented on ZOOKEEPER-2494:
---

Hey [~abrahamfine], this issue looks like a nice have for 3.4.10 release! :) Do 
you plan to work on it? If not, do you mind if I submit a PR?

> reword documentation to say "a simple shell to execute file-like operations" 
> instead of "a shell in which to execute simple file-system-like operations"
> 
>
> Key: ZOOKEEPER-2494
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2494
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.5.3
>
>
> [~rakeshr] mades this suggestion in ZOOKEEPER-2477 and I thought this was 
> worth implementing in its own jira



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2674) Projet-Final

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15843156#comment-15843156
 ] 

Edward Ribeiro commented on ZOOKEEPER-2674:
---

What is the problem [~salem-faraxen]? Can we close this?

/cc [~arshadmohammad] [~hanm]

> Projet-Final
> 
>
> Key: ZOOKEEPER-2674
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2674
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2673) projet

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15843155#comment-15843155
 ] 

Edward Ribeiro commented on ZOOKEEPER-2673:
---

What is the problem [~salem-faraxen]? Can we close this?

/cc [~arshadmohammad] [~hanm]

> projet
> --
>
> Key: ZOOKEEPER-2673
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2673
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2680) Correct DataNode.getChildren() inconsistent behavior.

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15842908#comment-15842908
 ] 

Edward Ribeiro commented on ZOOKEEPER-2680:
---

A few comments:

{code}
private static Set EMPTY_SET = Collections.unmodifiableSet(new 
HashSet(0));
{code}

is lacking the *final* modifier. Also, it can be:

{code}
private static final Set EMPTY_SET = Collections.emptySet();
{code}

About {{DataNode.setChildren()}} (would love the comments of [~breed] and 
[~fpj], as I can be about to write something utterly stupid :o) ): 

{code}
public synchronized void setChildren(HashSet children) {
this.children = children;
}
{code}

The code above could potentially pass a null. Is this behaviour expected? Say, 
instead of providing a {{DataNode.clear()}} method we just pass 
{{DataNode.setChildren(null)}} to reset all the children? Also, passing an 
alien reference (children) that can be changed outside the scope of 
{{DataNode}} seems potentially dangerous too. IMHO, {{DataNode.setChildren}} 
could have been coded more defensively. I would have done something akin the 
code below, but *of course* performance considerations should be taken into 
account. 

{code}
public synchronized void setChildren(Set children) {
if (children == null || children.isEmpty()) // isEmpty() is optional
   return;
if (this.children == null)
   this.children = new HashSet<>(8);
this.children.addAll(children);
}

// new method
public synchronized void clear() {
 children.clear();
}
{code}

All in all, I am +1 with this patch. :) Only took the opportunity to clarify 
this {{DataNode.setChildren}} method use, but I think we can commit this patch 
without changing the method just cited.

> Correct DataNode.getChildren() inconsistent behavior.
> -
>
> Key: ZOOKEEPER-2680
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2680
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.9, 3.5.1
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2680-01.patch
>
>
> DataNode.getChildren() API returns null and empty set if there are no 
> children in it depending on when the API is called. DataNode.getChildren() 
> API behavior should be changed and it should always return empty set if the 
> node does not have any child
> *DataNode.getChildren() API Current Behavior:*
> # returns null initially
> When DataNode is created and no children are added yet, 
> DataNode.getChildren() returns null
> # returns empty set after all the children are deleted:
> created a Node
> add a child
> delete the child
> DataNode.getChildren() returns empty set.
> After fix DataNode.getChildren() should return empty set in all the above 
> cases.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2464) NullPointerException on ContainerManager

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840464#comment-15840464
 ] 

Edward Ribeiro commented on ZOOKEEPER-2464:
---

Yeah... makes sense, it's pretty inconsistent behavior. It would require some 
defensive code as {{DataNode.setChildren(null)}} could introduce the null 
again. In fact, it is a total  refactoring of {{DataNode}}, albeit a small 
class. Wdyt [~randgalt]? 

> NullPointerException on ContainerManager
> 
>
> Key: ZOOKEEPER-2464
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2464
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Stefano Salmaso
>Assignee: Jordan Zimmerman
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ContainerManagerTest.java, ZOOKEEPER-2464.patch
>
>
> I would like to expose you to a problem that we are experiencing.
> We are using a cluster of 7 zookeeper and we use them to implement a 
> distributed lock using Curator 
> (http://curator.apache.org/curator-recipes/shared-reentrant-lock.html)
> So .. we tried to play with the servers to see if everything worked properly 
> and we stopped and start servers to see that the system worked well
> (like stop 03, stop 05, stop 06, start 05, start 06, start 03)
> We saw a strange behavior.
> The number of znodes grew up without stopping (normally we had 4000 or 5000, 
> we got to 60,000 and then we stopped our application)
> In zookeeeper logs I saw this (on leader only, one every minute)
> 2016-07-04 14:53:50,302 [myid:7] - ERROR 
> [ContainerManagerTask:ContainerManager$1@84] - Error checking containers
> java.lang.NullPointerException
>at 
> org.apache.zookeeper.server.ContainerManager.getCandidates(ContainerManager.java:151)
>at 
> org.apache.zookeeper.server.ContainerManager.checkContainers(ContainerManager.java:111)
>at 
> org.apache.zookeeper.server.ContainerManager$1.run(ContainerManager.java:78)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> We have not yet deleted the data ... so the problem can be reproduced on our 
> servers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: ZooKeeper 3.4.10 release discussion

[Edward Ribeiro]

>> newly
> >>>>>> added lines in orange color to understand the changes. The following
> >>>>>> sections has been modified:
> >>>>>>
> >>>>>>  - *Updating the release branch -> modified steps **1, 4, 10, 11*
> >>>>>>  - *Building -> modified step 9*
> >>>>>>  - *Publishing -> modified step 1*
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Rakesh
> >>>>>>
> >>>>>> On Tue, Jan 17, 2017 at 11:36 AM, Patrick Hunt <ph...@apache.org>
> >>>> wrote:
> >>>>>>
> >>>>>>> Perhaps you can make the changes directly on the wiki page as a
> >>>>> duplicate
> >>>>>>> line item under the original in a different color? It's hard for me
> >> to
> >>>>>>> really follow, esp as it's not a 1:1 replacement iiuc. Could you
> try
> >>>>>>> editing the wiki directly to start with, leave the original line
> and
> >>>> add
> >>>>>>> the new line(s) but in another color or some other indication?
> >>>>>>>
> >>>>>>> Thanks Rakesh.
> >>>>>>>
> >>>>>>> Patrick
> >>>>>>>
> >>>>>>> On Mon, Jan 16, 2017 at 8:48 AM, Rakesh Radhakrishnan <
> >>>>> rake...@apache.org
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi folks,
> >>>>>>>>
> >>>>>>>> As we all know, 3.4.10 release is the first ZooKeeper release
> after
> >>>>> the
> >>>>>>>> github repository migration. I have tried an attempt to modify the
> >>>>> steps
> >>>>>>>> described in the '
> >>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> HowToRelease'
> >>>>>>> page
> >>>>>>>> to
> >>>>>>>> make the release. Since this release is from an already created
> >>>>> branch,
> >>>>>>> I
> >>>>>>>> have focused only the branch related parts in cwiki and below
> >>>> sections
> >>>>>>> in
> >>>>>>>> the page needed changes like,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> *Updating the release branch*
> >>>>>>>> 1. Check out the branch with:
> >>>>>>>> git clone -b branch-X.Y
> >>>>>>>> https://git-wip-us.apache.org/repos/asf/zookeeper.git
> >>>>>>>>
> >>>>>>>> 2. I'm skipping this step, which is not required now.
> >>>>>>>>
> >>>>>>>> 4. Update CHANGES.txt with the committed jira details. As we
> follow
> >>>> PR
> >>>>>>>> merging, most of the jira info is not updated in this file. I
> >>>> believe
> >>>>>>>> release manager need to update this file to capture the jira
> details
> >>>>>>> marked
> >>>>>>>> for that release.
> >>>>>>>>
> >>>>>>>> 10. Commit these changes.
> >>>>>>>> git commit -a -m "Preparing for release X.Y.Z"
> >>>>>>>> git push  
> >>>>>>>>
> >>>>>>>> 11. Tag the release candidate (R is the release candidate number,
> >>>> and
> >>>>>>>> starts from 0):
> >>>>>>>> git tag -s release-X.Y.Z-rcR -m "ZooKeeper X.Y.Z-rcR release."
> >>>>>>>>
> >>>>>>>> Push the newly created rc tag to the remote repo.
> >>>>>>>> git push  release-X.Y.Z-rcR
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> *Building*
> >>>>>>>> 9. Call for a release vote on dev
> >>>>>>>> In the release candidate dev mail format, it needs to
> >>>> change
> >>>>>>> the
> >>>>>>>> tag like,

[jira] [Commented] (ZOOKEEPER-2395) allow ant command line control of junit test jvm args

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839502#comment-15839502
 ] 

Edward Ribeiro commented on ZOOKEEPER-2395:
---

oops, *excuse me* [~hanm] for skipping this comment on ZK-2664, shame on me. :(

Agree with you. 

> allow ant command line control of junit test jvm args
> -
>
> Key: ZOOKEEPER-2395
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2395
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build, tests
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.5.3, 3.6.0, 3.4.11
>
>
> We're seeing some failing jobs (see below) and the speculation is that it 
> might be due to ipv6 vs ipv4 usage. It would be nice to turn on "prefer ipv4" 
> in the jvm but there is no easy way to do that. I'll propose that we add a 
> variable to ant that's passed through to the jvm.
> 
> This is very odd. It failed 2 of the last three times it was run on H9
> with the following:
> 2016-03-20 06:06:18,480 [myid:] - INFO
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@74] - TEST METHOD FAILED
> testBindByAddress
> java.net.SocketException: No such device
> at java.net.NetworkInterface.isLoopback0(Native Method)
> at java.net.NetworkInterface.isLoopback(NetworkInterface.java:339)
> at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
> https://builds.apache.org/job/ZooKeeper_branch34/buildTimeTrend
> Why would it pass one of the times though if there is no loopback
> device on the host? That seems very odd!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro resolved ZOOKEEPER-2573.
---
Resolution: Fixed

> Modify Info.REVISION to adapt git repo
> --
>
> Key: ZOOKEEPER-2573
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: build, server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Mohammad Arshad
>    Assignee: Edward Ribeiro
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo 
> revision
> Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo 
> revision which is of type int
> But after migrating to git repo the git repo's revision(commit 
> 63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
> So either we should modify this variable to string to introduce new variable 
> to store the git revision and leave the svn revision variable unchanged.
> build.xml, and org.apache.zookeeper.version.util.VerGen also need to be 
> modified. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (ZOOKEEPER-2646) Java target in branch 3.4 doesn't match documentation

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15837652#comment-15837652
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2646 at 1/25/17 12:39 PM:
-

[~fpj], [~hanm], Hi guys!

For whatever reason, the related PR ( 
https://github.com/apache/zookeeper/pull/127 ) was not closed even tough the PR 
was merged into branch-3.4: 
https://github.com/apache/zookeeper/commit/7fd0884b0d6577162d71aedc460a588576cd483a

Flavio, only you or INFRA can close the GH PR, afaik. Would you mind to close 
the PR?

Cheers!


was (Author: eribeiro):
[~fpj], [~hanm], Hi guys!

For whatever reason, this issue and related PR ( 
https://github.com/apache/zookeeper/pull/127 ) were not closed even tough the 
PR was merged into branch-3.4: 
https://github.com/apache/zookeeper/commit/7fd0884b0d6577162d71aedc460a588576cd483a

Flavio, only you or INFRA can close the GH PR, afaik. Would you mind to close 
both (JIRA and PR)?

Cheers!

> Java target in branch 3.4 doesn't match documentation 
> --
>
> Key: ZOOKEEPER-2646
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2646
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.4.10
>
>
> Need to update build.xml 1.5->1.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2646) Java target in branch 3.4 doesn't match documentation

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15837652#comment-15837652
 ] 

Edward Ribeiro commented on ZOOKEEPER-2646:
---

[~fpj], [~hanm], Hi guys!

For whatever reason, this issue and related PR ( 
https://github.com/apache/zookeeper/pull/127 ) were not closed even tough the 
PR was merged into branch-3.4: 
https://github.com/apache/zookeeper/commit/7fd0884b0d6577162d71aedc460a588576cd483a

Flavio, only you or INFRA can close the GH PR, afaik. Would you mind to close 
both (JIRA and PR)?

Cheers!

> Java target in branch 3.4 doesn't match documentation 
> --
>
> Key: ZOOKEEPER-2646
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2646
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.4.10
>
>
> Need to update build.xml 1.5->1.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2395) allow ant command line control of junit test jvm args

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15837645#comment-15837645
 ] 

Edward Ribeiro commented on ZOOKEEPER-2395:
---

[~hanm], is this issue a duplicate of ZOOKEEPER-2664? I think so, and if I am 
right we should close it, right? Do you agree [~phunt]?

> allow ant command line control of junit test jvm args
> -
>
> Key: ZOOKEEPER-2395
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2395
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build, tests
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> We're seeing some failing jobs (see below) and the speculation is that it 
> might be due to ipv6 vs ipv4 usage. It would be nice to turn on "prefer ipv4" 
> in the jvm but there is no easy way to do that. I'll propose that we add a 
> variable to ant that's passed through to the jvm.
> 
> This is very odd. It failed 2 of the last three times it was run on H9
> with the following:
> 2016-03-20 06:06:18,480 [myid:] - INFO
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@74] - TEST METHOD FAILED
> testBindByAddress
> java.net.SocketException: No such device
> at java.net.NetworkInterface.isLoopback0(Native Method)
> at java.net.NetworkInterface.isLoopback(NetworkInterface.java:339)
> at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
> https://builds.apache.org/job/ZooKeeper_branch34/buildTimeTrend
> Why would it pass one of the times though if there is no loopback
> device on the host? That seems very odd!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2676) Enable remote debugging unit tests on CLI

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro updated ZOOKEEPER-2676:
--
Description: 
Sometimes it's useful to be able to run a unit test from the CLI and then 
attach an IDE to enable debugging as below:

{code}
$ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
{code}

The unit test will stop as below:

{code}
(...)
junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes. 
[junit] Listening for transport dt_socket at address: 5005
{code}

And we will be able to put breakpoints on the target class and bind the IDE to 
it's process to step through the test.

  was:
Sometimes it's useful to be able to run a unit test from the CLI and then 
attach an IDEA to enable debugging as below:

{code}
$ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
{code}

The unit test will stop as below:

{code}
(...)
junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes. 
[junit] Listening for transport dt_socket at address: 5005
{code}

And we will be able to put breakpoints on the target class and bind the IDE to 
it's process to step through the test.


> Enable remote debugging unit tests on CLI
> -
>
> Key: ZOOKEEPER-2676
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2676
> Project: ZooKeeper
>  Issue Type: Improvement
>    Reporter: Edward Ribeiro
>        Assignee: Edward Ribeiro
>Priority: Minor
>
> Sometimes it's useful to be able to run a unit test from the CLI and then 
> attach an IDE to enable debugging as below:
> {code}
> $ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
> {code}
> The unit test will stop as below:
> {code}
> (...)
> junit.run-concurrent:
>  [echo] Running 1 concurrent JUnit processes. 
> [junit] Listening for transport dt_socket at address: 5005
> {code}
> And we will be able to put breakpoints on the target class and bind the IDE 
> to it's process to step through the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ZOOKEEPER-2676) Enable remote debugging unit tests on CLI

[Edward Ribeiro (JIRA)]

Edward Ribeiro created ZOOKEEPER-2676:
-

 Summary: Enable remote debugging unit tests on CLI
 Key: ZOOKEEPER-2676
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2676
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Minor


Sometimes it's useful to be able to run a unit test from the CLI and then 
attach an IDEA to enable debugging as below:

{code}
$ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
{code}

The unit test will stop as below:

{code}
(...)
junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes. 
[junit] Listening for transport dt_socket at address: 5005
{code}

And we will be able to put breakpoints on the target class and bind the IDE to 
it's process to step through the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ZOOKEEPER-2675) Bump Mockito to version 2

[Edward Ribeiro (JIRA)]

Edward Ribeiro created ZOOKEEPER-2675:
-

 Summary: Bump Mockito to version 2
 Key: ZOOKEEPER-2675
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2675
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Trivial


Current mockito version is 1.8.2, but version 2 brings new improvements while 
keeping backwards compatibility to jdk6 (branch-3.4) and support partially 
jdk8. So, this issue is to bring mockito version up to date.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (ZOOKEEPER-2464) NullPointerException on ContainerManager

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15836766#comment-15836766
 ] 

Edward Ribeiro edited comment on ZOOKEEPER-2464 at 1/25/17 9:54 AM:


+1, LGTM.

Hey, [~randgalt], I have just seen that ZK projects imports mockito framework 
but only uses it on a single test case (as far as my quick-and-dirty search 
showed).

*If you want to add a test case to this bug*, then I am attaching a class that 
can be uses mockito to do so. If you decide it's too much boilerplate for 
little benefit then no problem leaving it out of this patch. *It's up to you to 
include it or not, just an idea*. :)

In either case, we are good to go with this patch, IMHO. Please, any committer 
would mind to merge it as soon as possible?

/cc [~hanm], [~arshadmohammad]?


was (Author: eribeiro):
+1, lgtm. Hey, [~randgalt], I have just seen that ZK projects imports mockito 
framework but only uses it on a single test case (as far as my quick-and-dirty 
search showed).

*If you want to add a test case to this bug*, then I am attaching a class that 
can be uses mockito to do so. If you decide it's too much boilerplate for 
little benefit then no problem leaving it out of this patch. *It's up to you to 
include it or not, just an idea*. :)

In either case, we are good to go with this patch, IMHO. Please, any committer 
would mind to merge it as soon as possible?

/cc [~hanm], [~arshadmohammad]?

> NullPointerException on ContainerManager
> 
>
> Key: ZOOKEEPER-2464
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2464
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Stefano Salmaso
>Assignee: Jordan Zimmerman
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ContainerManagerTest.java, ZOOKEEPER-2464.patch
>
>
> I would like to expose you to a problem that we are experiencing.
> We are using a cluster of 7 zookeeper and we use them to implement a 
> distributed lock using Curator 
> (http://curator.apache.org/curator-recipes/shared-reentrant-lock.html)
> So .. we tried to play with the servers to see if everything worked properly 
> and we stopped and start servers to see that the system worked well
> (like stop 03, stop 05, stop 06, start 05, start 06, start 03)
> We saw a strange behavior.
> The number of znodes grew up without stopping (normally we had 4000 or 5000, 
> we got to 60,000 and then we stopped our application)
> In zookeeeper logs I saw this (on leader only, one every minute)
> 2016-07-04 14:53:50,302 [myid:7] - ERROR 
> [ContainerManagerTask:ContainerManager$1@84] - Error checking containers
> java.lang.NullPointerException
>at 
> org.apache.zookeeper.server.ContainerManager.getCandidates(ContainerManager.java:151)
>at 
> org.apache.zookeeper.server.ContainerManager.checkContainers(ContainerManager.java:111)
>at 
> org.apache.zookeeper.server.ContainerManager$1.run(ContainerManager.java:78)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> We have not yet deleted the data ... so the problem can be reproduced on our 
> servers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2464) NullPointerException on ContainerManager

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro updated ZOOKEEPER-2464:
--
Attachment: ContainerManagerTest.java

+1, lgtm. Hey, [~randgalt], I have just seen that ZK projects imports mockito 
framework but only uses it on a single test case (as far as my quick-and-dirty 
search showed).

*If you want to add a test case to this bug*, then I am attaching a class that 
can be uses mockito to do so. If you decide it's too much boilerplate for 
little benefit then no problem leaving it out of this patch. *It's up to you to 
include it or not, just an idea*. :)

In either case, we are good to go with this patch, IMHO. Please, any committer 
would mind to merge it as soon as possible?

/cc [~hanm], [~arshadmohammad]?

> NullPointerException on ContainerManager
> 
>
> Key: ZOOKEEPER-2464
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2464
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Stefano Salmaso
>Assignee: Jordan Zimmerman
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ContainerManagerTest.java, ZOOKEEPER-2464.patch
>
>
> I would like to expose you to a problem that we are experiencing.
> We are using a cluster of 7 zookeeper and we use them to implement a 
> distributed lock using Curator 
> (http://curator.apache.org/curator-recipes/shared-reentrant-lock.html)
> So .. we tried to play with the servers to see if everything worked properly 
> and we stopped and start servers to see that the system worked well
> (like stop 03, stop 05, stop 06, start 05, start 06, start 03)
> We saw a strange behavior.
> The number of znodes grew up without stopping (normally we had 4000 or 5000, 
> we got to 60,000 and then we stopped our application)
> In zookeeeper logs I saw this (on leader only, one every minute)
> 2016-07-04 14:53:50,302 [myid:7] - ERROR 
> [ContainerManagerTask:ContainerManager$1@84] - Error checking containers
> java.lang.NullPointerException
>at 
> org.apache.zookeeper.server.ContainerManager.getCandidates(ContainerManager.java:151)
>at 
> org.apache.zookeeper.server.ContainerManager.checkContainers(ContainerManager.java:111)
>at 
> org.apache.zookeeper.server.ContainerManager$1.run(ContainerManager.java:78)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> We have not yet deleted the data ... so the problem can be reproduced on our 
> servers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2359) ZooKeeper client has unnecessary logs for watcher removal errors

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15836706#comment-15836706
 ] 

Edward Ribeiro commented on ZOOKEEPER-2359:
---

+1, lgtm. Please, [~hanm] and/or [~arshadmohammad], could you please take a 
look? :) 

[~randgalt], those changes need to be applied to {{master}} and {{branch-3.5}}, 
right? Didn't find on {{branch-3.4}}...

> ZooKeeper client has unnecessary logs for watcher removal errors
> 
>
> Key: ZOOKEEPER-2359
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2359
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: java client
>Affects Versions: 3.5.1
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Attachments: ZOOKEEPER-2359.patch
>
>
> ClientCnxn.java logs errors during watcher removal:
> LOG.error("Failed to find watcher!", nwe);
> LOG.error("Exception when removing watcher", ke);
> An error code/exception is generated so the logs are noisy and unnecessary. 
> If the client handles the error there's still a log message. This is 
> different than other APIs. These logs should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Running a single unit test

[Edward Ribeiro]

Oh, got it!

If I run

ant -Dtestcase=WatchManagerPerf test-core-java

it will work as yours. :D

But if I add a "test" word, like

ant test -Dtestcase=CreateTest

or

ant -Dtestcase=CreateTest test

then it will execute the 'CreateTest' only for the java code, but then will
execute the C tests. Even if I add 'test-core-java'.

Both https://wiki.apache.org/hadoop/ZooKeeper/HowToContribute and
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
instruct to add the "test" word even when using the 'testcase' switch, so
maybe we should update those docs.

Cheers,
Eddie




On Mon, Jan 23, 2017 at 6:44 PM, Michael Han <h...@cloudera.com> wrote:

> >> Only that the C tests
> run afterwards in spite of the "test-core-java" switch option.
>
> This sounds odd. I just did a test:
>
> 1. Sync latest master branch.
>
> 2. ant -Dtestcase=WatchManagerPerf test-core-java
>
> I got what I expected.
>
> *junit.run-single:*
>
> *junit.run-concurrent:*
>
> * [echo] Running 1 concurrent JUnit processes.*
>
> *junit.run:*
>
> *test-core-java:*
>
> *BUILD SUCCESSFUL*
>
> *Total time: 9 seconds*
>
> On Mon, Jan 23, 2017 at 12:18 PM, Edward Ribeiro <edward.ribe...@gmail.com
> >
> wrote:
>
> > +1 about moving ZK-2223 to branch-3.4.
> >
> > Some context about my particular question: I am able to run a single test
> > case and a single unit test method in a test class. Only that the C tests
> > run afterwards in spite of the "test-core-java" switch option. But it's a
> > minor annoyance, not a real problem. I just CTRL+C if not interested on
> the
> > C tests.
> >
> > On Mon, Jan 23, 2017 at 5:44 PM, Michael Han <h...@cloudera.com> wrote:
> >
> > > More info
> > >
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-2223
> > >
> > > We might want to get this in branch-3.4 as well - it is a useful
> feature
> > > for tests.
> > >
> > > On Mon, Jan 23, 2017 at 11:39 AM, Michael Han <h...@cloudera.com>
> wrote:
> > >
> > > > Maybe for Java test
> > > > ant -Dtestcase=case -Dtestmethod=method ? I at least used it
> > successfully
> > > > on master for a couple of times.
> > > >
> > > > I am not sure how to run a single C test though through ant - I ended
> > up
> > > > modifying makefile / test driver to do that instead.
> > > >
> > > > On Mon, Jan 23, 2017 at 11:31 AM, Edward Ribeiro <
> > > edward.ribe...@gmail.com
> > > > > wrote:
> > > >
> > > >> Nope. :(
> > > >>
> > > >> For what is worst: I remember it being able to run *only* a single
> > test
> > > >> many years ago (~ 2012/2013).
> > > >>
> > > >> On Mon, Jan 23, 2017 at 5:16 PM, Michael Han <h...@cloudera.com>
> > wrote:
> > > >>
> > > >> > ant -Dtestcase=foobar test-core-java ?
> > > >> >
> > > >> > On Mon, Jan 23, 2017 at 11:04 AM, Edward Ribeiro <
> > > >> edward.ribe...@gmail.com
> > > >> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hello community,
> > > >> > >
> > > >> > > I am used to run a single unit test with the following command:
> > > >> > >
> > > >> > > ant -Dtestcase=CreateTest test
> > > >> > >
> > > >> > > where "-Dtestcase" especifies the test class name as described
> > here:
> > > >> > > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > HowToContribute
> > > >> > >
> > > >> > > But for many months, I have seen that, after running the single
> > unit
> > > >> > test,
> > > >> > > Ant tries to execute the following C++ tests instead of just
> > > stopping
> > > >> as
> > > >> > > you can seee below.
> > > >> > >
> > > >> > > Any idea on how to force Ant to stop once it has run the single
> > > test?
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Edward
> > > >> > >
> > > >> > > PS: If this machine had the C libs properly configured it would
> > run
> > > >> all
> > > >> > the
> > > >> > > C/C++ tes

Re: Running a single unit test

[Edward Ribeiro]

+1 about moving ZK-2223 to branch-3.4.

Some context about my particular question: I am able to run a single test
case and a single unit test method in a test class. Only that the C tests
run afterwards in spite of the "test-core-java" switch option. But it's a
minor annoyance, not a real problem. I just CTRL+C if not interested on the
C tests.

On Mon, Jan 23, 2017 at 5:44 PM, Michael Han <h...@cloudera.com> wrote:

> More info
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2223
>
> We might want to get this in branch-3.4 as well - it is a useful feature
> for tests.
>
> On Mon, Jan 23, 2017 at 11:39 AM, Michael Han <h...@cloudera.com> wrote:
>
> > Maybe for Java test
> > ant -Dtestcase=case -Dtestmethod=method ? I at least used it successfully
> > on master for a couple of times.
> >
> > I am not sure how to run a single C test though through ant - I ended up
> > modifying makefile / test driver to do that instead.
> >
> > On Mon, Jan 23, 2017 at 11:31 AM, Edward Ribeiro <
> edward.ribe...@gmail.com
> > > wrote:
> >
> >> Nope. :(
> >>
> >> For what is worst: I remember it being able to run *only* a single test
> >> many years ago (~ 2012/2013).
> >>
> >> On Mon, Jan 23, 2017 at 5:16 PM, Michael Han <h...@cloudera.com> wrote:
> >>
> >> > ant -Dtestcase=foobar test-core-java ?
> >> >
> >> > On Mon, Jan 23, 2017 at 11:04 AM, Edward Ribeiro <
> >> edward.ribe...@gmail.com
> >> > >
> >> > wrote:
> >> >
> >> > > Hello community,
> >> > >
> >> > > I am used to run a single unit test with the following command:
> >> > >
> >> > > ant -Dtestcase=CreateTest test
> >> > >
> >> > > where "-Dtestcase" especifies the test class name as described here:
> >> > > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> HowToContribute
> >> > >
> >> > > But for many months, I have seen that, after running the single unit
> >> > test,
> >> > > Ant tries to execute the following C++ tests instead of just
> stopping
> >> as
> >> > > you can seee below.
> >> > >
> >> > > Any idea on how to force Ant to stop once it has run the single
> test?
> >> > >
> >> > > Thanks,
> >> > > Edward
> >> > >
> >> > > PS: If this machine had the C libs properly configured it would run
> >> all
> >> > the
> >> > > C/C++ tests.
> >> > >
> >> > > 
> >> > > 
> >> > >
> >> > > junit.run-concurrent:
> >> > >  [echo] Running 1 concurrent JUnit processes.
> >> > > [junit] Running org.apache.zookeeper.test.CreateTest
> >> > > [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time
> >> > elapsed:
> >> > > 1,105 sec
> >> > >
> >> > > junit.run:
> >> > >
> >> > > test-core-java:
> >> > >
> >> > > call-test-cppunit:
> >> > >
> >> > > init:
> >> > >
> >> > > check-cppunit-makefile:
> >> > >
> >> > > create-cppunit-makefile:
> >> > >
> >> > > init:
> >> > >
> >> > > ivy-download:
> >> > >
> >> > > ivy-taskdef:
> >> > >
> >> > > ivy-init:
> >> > >
> >> > > ivy-retrieve:
> >> > > [ivy:retrieve] :: loading settings :: file =
> >> > > /home/eribeiro/IdeaProjects/zookeeper/ivysettings.xml
> >> > > [ivy:retrieve] :: resolving dependencies ::
> >> > > org.apache.zookeeper#zookeeper;3.6.0-SNAPSHOT
> >> > > [ivy:retrieve] confs: [default]
> >> > > [ivy:retrieve] found jline#jline;2.11 in maven2
> >> > > [ivy:retrieve] found org.eclipse.jetty#jetty-
> server;9.2.18.v20160721
> >> in
> >> > > maven2
> >> > > [ivy:retrieve] found javax.servlet#javax.servlet-api;3.1.0 in
> maven2
> >> > > [ivy:retrieve] found org.eclipse.jetty#jetty-http;9.2.18.v20160721
> in
> >> > > maven2
> >> > > [ivy:retrieve]

Re: Running a single unit test

[Edward Ribeiro]

Nope. :(

For what is worst: I remember it being able to run *only* a single test
many years ago (~ 2012/2013).

On Mon, Jan 23, 2017 at 5:16 PM, Michael Han <h...@cloudera.com> wrote:

> ant -Dtestcase=foobar test-core-java ?
>
> On Mon, Jan 23, 2017 at 11:04 AM, Edward Ribeiro <edward.ribe...@gmail.com
> >
> wrote:
>
> > Hello community,
> >
> > I am used to run a single unit test with the following command:
> >
> > ant -Dtestcase=CreateTest test
> >
> > where "-Dtestcase" especifies the test class name as described here:
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> >
> > But for many months, I have seen that, after running the single unit
> test,
> > Ant tries to execute the following C++ tests instead of just stopping as
> > you can seee below.
> >
> > Any idea on how to force Ant to stop once it has run the single test?
> >
> > Thanks,
> > Edward
> >
> > PS: If this machine had the C libs properly configured it would run all
> the
> > C/C++ tests.
> >
> > 
> > 
> >
> > junit.run-concurrent:
> >  [echo] Running 1 concurrent JUnit processes.
> > [junit] Running org.apache.zookeeper.test.CreateTest
> > [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed:
> > 1,105 sec
> >
> > junit.run:
> >
> > test-core-java:
> >
> > call-test-cppunit:
> >
> > init:
> >
> > check-cppunit-makefile:
> >
> > create-cppunit-makefile:
> >
> > init:
> >
> > ivy-download:
> >
> > ivy-taskdef:
> >
> > ivy-init:
> >
> > ivy-retrieve:
> > [ivy:retrieve] :: loading settings :: file =
> > /home/eribeiro/IdeaProjects/zookeeper/ivysettings.xml
> > [ivy:retrieve] :: resolving dependencies ::
> > org.apache.zookeeper#zookeeper;3.6.0-SNAPSHOT
> > [ivy:retrieve] confs: [default]
> > [ivy:retrieve] found jline#jline;2.11 in maven2
> > [ivy:retrieve] found org.eclipse.jetty#jetty-server;9.2.18.v20160721 in
> > maven2
> > [ivy:retrieve] found javax.servlet#javax.servlet-api;3.1.0 in maven2
> > [ivy:retrieve] found org.eclipse.jetty#jetty-http;9.2.18.v20160721 in
> > maven2
> > [ivy:retrieve] found org.eclipse.jetty#jetty-util;9.2.18.v20160721 in
> > maven2
> > [ivy:retrieve] found org.eclipse.jetty#jetty-io;9.2.18.v20160721 in
> maven2
> > [ivy:retrieve] found org.eclipse.jetty#jetty-servlet;9.2.18.v20160721 in
> > maven2
> > [ivy:retrieve] found org.eclipse.jetty#jetty-security;9.2.18.v20160721
> in
> > maven2
> > [ivy:retrieve] found org.codehaus.jackson#jackson-mapper-asl;1.9.11 in
> > maven2
> > [ivy:retrieve] found org.codehaus.jackson#jackson-core-asl;1.9.11 in
> > maven2
> > [ivy:retrieve] found org.slf4j#slf4j-api;1.7.5 in maven2
> > [ivy:retrieve] found org.slf4j#slf4j-log4j12;1.7.5 in maven2
> > [ivy:retrieve] found commons-cli#commons-cli;1.2 in maven2
> > [ivy:retrieve] found log4j#log4j;1.2.17 in maven2
> > [ivy:retrieve] found io.netty#netty;3.10.5.Final in maven2
> > [ivy:retrieve] found net.java.dev.javacc#javacc;5.0 in maven2
> > [ivy:retrieve] :: resolution report :: resolve 116ms :: artifacts dl 5ms
> > -
> > |  |modules||   artifacts   |
> > |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> > -
> > |  default |   16  |   0   |   0   |   0   ||   16  |   0   |
> > -
> > [ivy:retrieve] :: retrieving :: org.apache.zookeeper#zookeeper
> > [ivy:retrieve] confs: [default]
> > [ivy:retrieve] 1 artifacts copied, 15 already retrieved (291kB/4ms)
> >
> > generate_jute_parser:
> > [ivy:artifactproperty] DEPRECATED: 'ivy.conf.file' is deprecated, use
> > 'ivy.settings.file' instead
> > [ivy:artifactproperty] :: loading settings :: file =
> > /home/eribeiro/IdeaProjects/zookeeper/ivysettings.xml
> >  [move] Moving 1 file to /home/eribeiro/IdeaProjects/
> > zookeeper/build/lib
> >[javacc] Java Compiler Compiler Version 5.0 (Parser Generator)
> >[javacc] (type "javacc" with no arguments for help)
> >[javacc] Reading from file
> > /home/eribeiro/IdeaProjects/zookeeper/src/java/main/org/
> > apache/jute/compile

Running a single unit test

[Edward Ribeiro]

Hello community,

I am used to run a single unit test with the following command:

ant -Dtestcase=CreateTest test

where "-Dtestcase" especifies the test class name as described here:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

But for many months, I have seen that, after running the single unit test,
Ant tries to execute the following C++ tests instead of just stopping as
you can seee below.

Any idea on how to force Ant to stop once it has run the single test?

Thanks,
Edward

PS: If this machine had the C libs properly configured it would run all the
C/C++ tests.



junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes.
[junit] Running org.apache.zookeeper.test.CreateTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
1,105 sec

junit.run:

test-core-java:

call-test-cppunit:

init:

check-cppunit-makefile:

create-cppunit-makefile:

init:

ivy-download:

ivy-taskdef:

ivy-init:

ivy-retrieve:
[ivy:retrieve] :: loading settings :: file =
/home/eribeiro/IdeaProjects/zookeeper/ivysettings.xml
[ivy:retrieve] :: resolving dependencies ::
org.apache.zookeeper#zookeeper;3.6.0-SNAPSHOT
[ivy:retrieve] confs: [default]
[ivy:retrieve] found jline#jline;2.11 in maven2
[ivy:retrieve] found org.eclipse.jetty#jetty-server;9.2.18.v20160721 in
maven2
[ivy:retrieve] found javax.servlet#javax.servlet-api;3.1.0 in maven2
[ivy:retrieve] found org.eclipse.jetty#jetty-http;9.2.18.v20160721 in maven2
[ivy:retrieve] found org.eclipse.jetty#jetty-util;9.2.18.v20160721 in maven2
[ivy:retrieve] found org.eclipse.jetty#jetty-io;9.2.18.v20160721 in maven2
[ivy:retrieve] found org.eclipse.jetty#jetty-servlet;9.2.18.v20160721 in
maven2
[ivy:retrieve] found org.eclipse.jetty#jetty-security;9.2.18.v20160721 in
maven2
[ivy:retrieve] found org.codehaus.jackson#jackson-mapper-asl;1.9.11 in
maven2
[ivy:retrieve] found org.codehaus.jackson#jackson-core-asl;1.9.11 in maven2
[ivy:retrieve] found org.slf4j#slf4j-api;1.7.5 in maven2
[ivy:retrieve] found org.slf4j#slf4j-log4j12;1.7.5 in maven2
[ivy:retrieve] found commons-cli#commons-cli;1.2 in maven2
[ivy:retrieve] found log4j#log4j;1.2.17 in maven2
[ivy:retrieve] found io.netty#netty;3.10.5.Final in maven2
[ivy:retrieve] found net.java.dev.javacc#javacc;5.0 in maven2
[ivy:retrieve] :: resolution report :: resolve 116ms :: artifacts dl 5ms
-
|  |modules||   artifacts   |
|   conf   | number| search|dwnlded|evicted|| number|dwnlded|
-
|  default |   16  |   0   |   0   |   0   ||   16  |   0   |
-
[ivy:retrieve] :: retrieving :: org.apache.zookeeper#zookeeper
[ivy:retrieve] confs: [default]
[ivy:retrieve] 1 artifacts copied, 15 already retrieved (291kB/4ms)

generate_jute_parser:
[ivy:artifactproperty] DEPRECATED: 'ivy.conf.file' is deprecated, use
'ivy.settings.file' instead
[ivy:artifactproperty] :: loading settings :: file =
/home/eribeiro/IdeaProjects/zookeeper/ivysettings.xml
 [move] Moving 1 file to /home/eribeiro/IdeaProjects/zookeeper/build/lib
   [javacc] Java Compiler Compiler Version 5.0 (Parser Generator)
   [javacc] (type "javacc" with no arguments for help)
   [javacc] Reading from file
/home/eribeiro/IdeaProjects/zookeeper/src/java/main/org/apache/jute/compiler/generated/rcc.jj
. . .
   [javacc] File "TokenMgrError.java" is being rebuilt.
   [javacc] File "ParseException.java" is being rebuilt.
   [javacc] File "Token.java" is being rebuilt.
   [javacc] File "SimpleCharStream.java" is being rebuilt.
   [javacc] Parser generated successfully.

jute:
[javac] Compiling 7 source files to
/home/eribeiro/IdeaProjects/zookeeper/build/classes
[javac] warning: [options] bootstrap class path not set in conjunction
with -source 1.7
[javac] 1 warning

compile_jute_uptodate:

compile_jute:

clover.setup:

clover.info:

clover:

ver-gen:

svn-revision:

version-info:
 [java] Unknown REVISION number, using -1

process-template:

build-generated:
[javac] Compiling 1 source file to
/home/eribeiro/IdeaProjects/zookeeper/build/classes
[javac] warning: [options] bootstrap class path not set in conjunction
with -source 1.7
[javac] 1 warning

compile:

jar:
  [jar] Building jar:
/home/eribeiro/IdeaProjects/zookeeper/build/zookeeper-3.6.0-SNAPSHOT.jar

check-cppunit-makefile:

create-cppunit-makefile:

test-cppunit:
 [exec] CDPATH="${ZSH_VERSION+.}:" && cd
/home/eribeiro/IdeaProjects/zookeeper/src/c && /bin/bash
/home/eribeiro/IdeaProjects/zookeeper/src/c/missing aclocal-1.14
 [exec] Makefile:709: recipe for target
'/home/eribeiro/IdeaProjects/zookeeper/src/c/aclocal.m4' failed
 [exec] 

[jira] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833908#comment-15833908
 ] 

Edward Ribeiro commented on ZOOKEEPER-2671:
---

The new method is the only change from ZK-2508 that we need to backport to 
branch-3.4???

I don't have time to look at the whole changeset now...

Best regards
 

> Compilation error in branch-3.4
> ---
>
> Key: ZOOKEEPER-2671
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2671
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-2671-01.patch
>
>
> branch-3.4 code compilation is failing. Following are the compilation erros:
> {code}
> compile-test:
> [mkdir] Created dir: D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] Compiling 146 source files to 
> D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
> [javac] 
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:464:
>  error: cannot find symbol
> [javac] ZooKeeper zk = ClientBase.createZKClient(HOSTPORT);
> [javac]  ^
> [javac]   symbol:   method createZKClient(String)
> [javac]   location: class ClientBase
> [javac] 
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:503:
>  error: cannot find symbol
> [javac] zk = ClientBase.createZKClient(HOSTPORT);
> [javac]^
> [javac]   symbol:   method createZKClient(String)
> [javac]   location: class ClientBase
> [javac] Note: Some input files use or override a deprecated API.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833892#comment-15833892
 ] 

Edward Ribeiro commented on ZOOKEEPER-2671:
---

Excuse me, you right [~rakeshr]! 

BTW, the error is reproducible with {{ant test compile}} and {{ant tar}}. As I 
could see, the ClientBase's method signature lacking on branch-3.4 was 
introduced by ZOOKEEPER-2508 (commit: 685a5268).

> Compilation error in branch-3.4
> ---
>
> Key: ZOOKEEPER-2671
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2671
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Attachments: ZOOKEEPER-2671-01.patch
>
>
> branch-3.4 code compilation is failing. Following are the compilation erros:
> {code}
> compile-test:
> [mkdir] Created dir: D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] Compiling 146 source files to 
> D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
> [javac] 
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:464:
>  error: cannot find symbol
> [javac] ZooKeeper zk = ClientBase.createZKClient(HOSTPORT);
> [javac]  ^
> [javac]   symbol:   method createZKClient(String)
> [javac]   location: class ClientBase
> [javac] 
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:503:
>  error: cannot find symbol
> [javac] zk = ClientBase.createZKClient(HOSTPORT);
> [javac]^
> [javac]   symbol:   method createZKClient(String)
> [javac]   location: class ClientBase
> [javac] Note: Some input files use or override a deprecated API.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833882#comment-15833882
 ] 

Edward Ribeiro commented on ZOOKEEPER-2664:
---

[~hanm], does this issue duplicates ZOOKEEPER-2395? Could you close that one 
too?

> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch exception from isLoopback() call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833878#comment-15833878
 ] 

Edward Ribeiro commented on ZOOKEEPER-2671:
---

[~arshad.mohammad], do you see this error on your local dev environment or 
jenkins CI?

I've just pulled the latest commit from branch-3.4 
(e93d5b27f1cc2c66df39b45be321e90c798bdc9b) and was able to {{ant clean 
compile}} on my laptop.

> Compilation error in branch-3.4
> ---
>
> Key: ZOOKEEPER-2671
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2671
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>
> branch-3.4 code compilation is failing. Following are the compilation erros:
> {code}
> compile-test:
> [mkdir] Created dir: D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] Compiling 146 source files to 
> D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
> [javac] 
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:464:
>  error: cannot find symbol
> [javac] ZooKeeper zk = ClientBase.createZKClient(HOSTPORT);
> [javac]  ^
> [javac]   symbol:   method createZKClient(String)
> [javac]   location: class ClientBase
> [javac] 
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:503:
>  error: cannot find symbol
> [javac] zk = ClientBase.createZKClient(HOSTPORT);
> [javac]^
> [javac]   symbol:   method createZKClient(String)
> [javac]   location: class ClientBase
> [javac] Note: Some input files use or override a deprecated API.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2670) CLONE - Connections fo ZooKeeper server becomes slow over time with native GSSAPI

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833875#comment-15833875
 ] 

Edward Ribeiro commented on ZOOKEEPER-2670:
---

Hey [~fittey], thanks for taking a stab at this issue. But cloning an issue is 
not the way we work here, AFAIK. 

First, we are switching to a Github based workflow, so you can clone the ZK 
repo from GH, make the changes in your branch and then submit as a PR to ZK at 
GH. So, attaching is not even required anymore. More details here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Second, it would be nice if you could sync with the current  ZOOKEEPER-2230 
assignee so that you can discuss and decide for a solution that covers both 
cases. In any case, the committers will have the final word and can decide what 
could fits bets to merge.

So, no need yet another JIRA issue to address the same problem. Please, close 
this one and discuss your solution (pinging committers if necessary) at  
ZOOKEEPER-2230. 

Best Regards!

> CLONE - Connections fo ZooKeeper server becomes slow over time with native 
> GSSAPI
> -
>
> Key: ZOOKEEPER-2670
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2670
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6, 3.4.7, 3.4.8, 3.5.0
> Environment: OS: RHEL6
> Java: 1.8.0_40
> Configuration:
> java.env:
> {noformat}
> SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Xmx5120m"
> SERVER_JVMFLAGS="$SERVER_JVMFLAGS 
> -Djava.security.auth.login.config=/local/apps/zookeeper-test1/conf/jaas-server.conf"
> SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Dsun.security.jgss.native=true"
> {noformat}
> jaas-server.conf:
> {noformat}
> Server {
> com.sun.security.auth.module.Krb5LoginModule required
> useKeyTab=true
> isInitiator=false
> principal="zookeeper/@";
> };
> {noformat}
> Process environment:
> {noformat}
> KRB5_KTNAME=/local/apps/zookeeper-test1/conf/keytab
> ZOO_LOG_DIR=/local/apps/zookeeper-test1/log
> ZOOCFGDIR=/local/apps/zookeeper-test1/conf
> {noformat}
>Reporter: Yan Fitterer
>Assignee: Enis Soztutar
>  Labels: patch
> Fix For: 3.4.6, 3.4.7, 3.4.8, 3.5.2
>
>
> ZooKeeper server becomes slow over time when native GSSAPI is used. The 
> connection to the server starts taking upto 10 seconds.
> This is happening with ZooKeeper-3.4.6 and is fairly reproducible.
> Debug logs:
> {noformat}
> 2015-07-02 00:58:49,318 [myid:] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:NIOServerCnxnFactory@197] - 
> Accepted socket connection from /:47942
> 2015-07-02 00:58:49,318 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@78] - 
> serviceHostname is ''
> 2015-07-02 00:58:49,318 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@79] - 
> servicePrincipalName is 'zookeeper'
> 2015-07-02 00:58:49,318 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@80] - SASL 
> mechanism(mech) is 'GSSAPI'
> 2015-07-02 00:58:49,324 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@106] - Added 
> private credential to subject: [GSSCredential: 
> zookeeper@ 1.2.840.113554.1.2.2 Accept [class 
> sun.security.jgss.wrapper.GSSCredElement]]
> 2015-07-02 00:58:59,441 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@810] - Session 
> establishment request from client /:47942 client's lastZxid is 0x0
> 2015-07-02 00:58:59,441 [myid:] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@868] - Client 
> attempting to establish new session at /:47942
> 2015-07-02 00:58:59,448 [myid:] - DEBUG 
> [SyncThread:0:FinalRequestProcessor@88] - Processing request:: 
> sessionid:0x14e486028785c81 type:createSession cxid:0x0 zxid:0x110e79 
> txntype:-10 reqpath:n/a
> 2015-07-02 00:58:59,448 [myid:] - DEBUG 
> [SyncThread:0:FinalRequestProcessor@160] - sessionid:0x14e486028785c81 
> type:createSession cxid:0x0 zxid:0x110e79 txntype:-10 reqpath:n/a
> 2015-07-02 00:58:59,448 [myid:] - INFO  [SyncThread:0:ZooKeeperServer@617] - 
> Established session 0x14e486028785c81 with negotiated timeout 1 for 
> client /:47942
> 2015-07-02 00:58:59,452 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@949] - Responding 
> to client SASL token.
> 2015-07-02 00:58:59,452 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:Zo

Re: [ANNOUNCE] New Apache ZooKeeper Committer: Mohammad Arshad

[Edward Ribeiro]

Congrats, Arshad! Super well deserved! :)

Cheers,
Eddie

Em 21 de jan de 2017 11:25 AM, "Flavio Junqueira"  escreveu:

> The Apache ZooKeeper PMC has voted to offer committership to Arshad and he
> accepted. Arshad has contributed significantly to this community in the
> recent past, and we expect his level of engagement and contribution to
> increase with committership.
>
> Congratulations, Arshad!
>
> -Flavio on behalf of the Apache ZooKeeper PMC

Re: Willing to Contribute to this Project

[Edward Ribeiro]

Um... gonna take a closer look on Curator soon, I hope.

Thanks Jordan!

On Tue, Jan 17, 2017 at 4:34 PM, Jordan Zimmerman <
jor...@jordanzimmerman.com> wrote:

> we have many Pull Requests that could use review:
> https://github.com/apache/curator/pulls  curator/pulls>
>
> Also, have a look at our Issues database. Look first at issues that have
> the most votes or have the highest priority: https://issues.apache.org/
> jira/browse/CURATOR 
>
> -Jordan
>
> > On Jan 17, 2017, at 11:50 AM, Amol Kulkarni  wrote:
> >
> > Hi there,
> >
> > This is Amol Kulkarni here,i'm looking forward to contribute to open
> source
> > projects in Java technologies and came across the zookeeper project.
> > I'm willing to contribute to make any changes/issues available.
> > I have been working Java technologies for the last 5 year's,looking
> forward
> > to contribute in projects.
> >
> > Would be very greatful,if get assistance  to get an idea how to start
> with
> > it.
> > Awaiting your response.
> >
> > --
> > *Thanks & Regards*
> > *Amol Kulkarni *
>
>

Re: Anyone interested in learning about our QA build? (ZK-2665)

[Edward Ribeiro]

Okay, I left two days to anyone step up. You can count on me. :) Where/How
do I start?

Edward

Em 14 de jan de 2017 3:39 PM, "Flavio Junqueira"  escreveu:

> If anyone wants to learn about our QA build, then working on
> ZOOKEEPER-2665 might be a good task. It is not a difficult task as it is
> mainly copying stuff from master, but you'd need to understand to copy the
> right stuff. I'm willing to guide anyone interested in doing this.
>
> I can definitely do it myself if no one else is interested in picking it
> up.
>
> -Flavio

[jira] [Commented] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822904#comment-15822904
 ] 

Edward Ribeiro commented on ZOOKEEPER-2659:
---

Cool, [~praste]! 

After my comment, I remembered that there was some work on Log4j done by 
[~arshad.mohammad] last year. Please, catch up with the following JIRAS:

https://issues.apache.org/jira/browse/ZOOKEEPER-2393

https://issues.apache.org/jira/browse/ZOOKEEPER-1371

Furthermore, this issue seems like a duplicate of 
https://issues.apache.org/jira/browse/ZOOKEEPER-2342 so I would advise you to 
ping [~cnauroth], so that you don't work on the same thing and catch up with 
the discussion there too.

Cheers! 


> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro updated ZOOKEEPER-2573:
--
Affects Version/s: 3.4.9
   3.5.2

> Modify Info.REVISION to adapt git repo
> --
>
> Key: ZOOKEEPER-2573
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: build, server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Arshad Mohammad
>    Assignee: Edward Ribeiro
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo 
> revision
> Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo 
> revision which is of type int
> But after migrating to git repo the git repo's revision(commit 
> 63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
> So either we should modify this variable to string to introduce new variable 
> to store the git revision and leave the svn revision variable unchanged.
> build.xml, and org.apache.zookeeper.version.util.VerGen also need to be 
> modified. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro updated ZOOKEEPER-2573:
--
Fix Version/s: 3.4.10

> Modify Info.REVISION to adapt git repo
> --
>
> Key: ZOOKEEPER-2573
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: build, server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Arshad Mohammad
>    Assignee: Edward Ribeiro
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo 
> revision
> Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo 
> revision which is of type int
> But after migrating to git repo the git repo's revision(commit 
> 63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
> So either we should modify this variable to string to introduce new variable 
> to store the git revision and leave the svn revision variable unchanged.
> build.xml, and org.apache.zookeeper.version.util.VerGen also need to be 
> modified. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821839#comment-15821839
 ] 

Edward Ribeiro commented on ZOOKEEPER-2659:
---

Thanks for taking a stab at this issue, [~praste]! 

The ZK project is switching to a Github based workflow so that it can be easier 
for contributors to submit patches and reviewers to take a look at the patch. 
Would you mind to submit a PR for this issue? your PR title should start as 
"ZOOKEEPER-2664:" so that it can automatically be linked to this JIRA issue. 
More details here under 'Pull requests via github (work in progress)' here 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards,
Edward

> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821830#comment-15821830
 ] 

Edward Ribeiro commented on ZOOKEEPER-2664:
---

Hi [~tedyu],

Thanks for the patch! :) The ZK project is switching to a Github based workflow 
so that it can be easier for contributors to submit PR and reviewers to take a 
look at the patch. Would you mind to submit a PR for this issue? your PR title 
should start as "ZOOKEEPER-2664:" so that it can automatically be linked to 
this JIRA issue. More details here under 'Pull requests via github (work in 
progress)' here 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute 

Secondly, this issue is a duplicate of 
https://issues.apache.org/jira/browse/ZOOKEEPER-2395 , I am marking it as so, 
but leave to [~phunt] to decide which one to keep and which one to close, but 
merging the comments & proposed solutions from both, of course.

Thirdly, I couldn't patch the file using both commands below. Are you sure you 
generated the patch with the command like:  {{git diff --no-prefix 
previous_commit..your_commit > ZOOKEEPER-2664.patch}} ?

Finally, would you mind to LOG a WARN message inside the catch block so that 
whoever looks at the log knows that this test was skipped because it had 
trouble finding the loopback interface?

Thanks


> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> 

Re: ZooKeeper 3.4.10 release discussion

[Edward Ribeiro]

Hi Rakesh,

Thansk for stepping up to this task! Pretty cool! :)

Do you think https://issues.apache.org/jira/browse/ZOOKEEPER-2573 is worth
targeting 3.4.10 too?

Edward



On Fri, Jan 13, 2017 at 7:56 AM, Rakesh Radhakrishnan 
wrote:

> Hi All,
>
> I hope to cut an RC in a week - giving some more time for your favorite
> outstanding blocker/critical issues. Will start moving out any tickets that
> are not blockers and/or won’t fit the timeline - there are 1 blocker, 5
> critical, 15 major, 7 minor tickets outstanding as of now. Appreciate your
> support in releasing 3.4.10 version. Thanks!
>
> Please find the open issues marked for 3.4.10 release here,
> https://goo.gl/XdraFA
>
> Thanks,
> Rakesh
>
>
> On Tue, Dec 6, 2016 at 4:15 PM, Rakesh Radhakrishnan 
> wrote:
>
> > Hi All,
> >
> > I am interested in going through the release process as the RM.
> >
> > Overall, I could see total 41 issues marked for 3.4.10 release as of now,
> > which includes 4 blockers, 5 critical, 20 major and 12 minor issues. I
> > count 9 issues fixed/committed already for 3.4.10 which includes 1
> blocker
> > and 1 critical(security related) issue. ZOOKEEPER-1045 is a much awaited
> > one and the feature code is committed. I think it is a good time to
> > initiate the discussion of 3.4.10 release processes.
> >
> > Please find the issues marked for 3.4.10 release here,
> > https://goo.gl/FfbpVG
> >
> > Currently, I'm focusing on updating ZOOKEEPER-1045 feature details into
> > our project cwiki and related ZOOKEEPER-2479 improvement jira. I'd like
> to
> > include ZOOKEEPER-2383 into this release if everyone agrees. Appreciate
> > your help in reviewing the jira patches and making it stable for release.
> > Also, please feel free to push your favorite issues ahead of 3.4.10
> release.
> >
> > I hope with the community support, we should be able to close all
> > necessary blockers/critical issues soon. Kindly requesting everyone to
> look
> > at the issues marked for 3.4.10 and push these asap or can be pushed out
> to
> > 3.4.11.
> >
> > Imp: Since we moved to github repository, the release procedure
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
> > requires changes. Appreciate your help in this part. Thanks!
> >
> > Please let me know your thoughts on the plan.
> >
> > Thanks,
> > Rakesh
> >
>

[jira] [Issue Comment Deleted] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Edward Ribeiro updated ZOOKEEPER-2664:
--
Comment: was deleted

(was: Hi [~ted_yu]
)

> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch exception from isLoopback() call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821789#comment-15821789
 ] 

Edward Ribeiro commented on ZOOKEEPER-2664:
---

Hi [~ted_yu]


> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch exception from isLoopback() call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)