Re: ZooKeeper 3.4.9 release discussion

[Rakesh Radhakrishnan]

On a second look, I think I need to update the existing 'releasenotes.html'
details by manually replace the contents with the jira for all the versions
as the page formatting is different for the existing content. Shall I
convert the existing content in this file to the new format ? Am I missing
anything here?

Rakesh

On Wed, Aug 17, 2016 at 10:57 AM, Rakesh Radhakrishnan 
wrote:

> It seems, https://github.com/apache/zookeeper/blob/branch-
> 3.4/docs/releasenotes.html beginning with "ZooKeeper 3.4.5 Release
> Notes". I hope I need to append the details of 3.4.6, 3.4.7, 3.4.8 first
> and then add our current 3.4.9 release notes, isn't it?
>
>
> Thanks,
> Rakesh
>
> On Wed, Aug 17, 2016 at 8:13 AM, Rakesh Radhakrishnan 
> wrote:
>
>> Thanks Patrick and Chris for quickly resolving this. I will continue with
>> the release procedures.
>>
>> Rakesh
>>
>> On Wed, Aug 17, 2016 at 4:50 AM, Patrick Hunt  wrote:
>>
>>> Great, thanks Chris!
>>>
>>> Patrick
>>>
>>> On Tue, Aug 16, 2016 at 4:16 PM, Chris Nauroth >> > wrote:
>>>
 I just committed the ZOOKEEPER-2514 patch.  Patrick, thank you for the
 quick turnaround.  Rakesh, I think you’re all set to proceed with release
 notes for the 3.4.9 release candidate.

 --Chris Nauroth

 On 8/16/16, 2:52 PM, "Patrick Hunt"  wrote:

 Rakesh pointed out that the current "how to release" docs no longer
 are
 correct for branch-3.4 as in branch-3.5 and later we updated the
 release
 notes creation process to simplify it. Used to be very manual, in
 3.5+ we
 moved to using the HTML available from Jira. I've created the
 following
 JIRA to backport that change to branch 3.4. After this patch is
 applied the
 RM process for release notes creation in 3.4 is consistent with the
 "how to
 release" documentation available on the wiki.

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

 Chris would you be able to take a look/review as well? That would
 help to
 unstick Rakesh with 3.4.9 (although he can review/commit as well
 but given
 the timezone diff...)

 Thanks,

 Patrick


 On Tue, Aug 16, 2016 at 10:55 AM, Chris Nauroth <
 cnaur...@hortonworks.com>
 wrote:

 > +1 for the plan.  Rakesh, thank you for working on the 3.4.9
 release.
 >
 > --Chris Nauroth
 >
 > On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan" 
 wrote:
 >
 > Hi All,
 >
 > I think we have given enough time to push issues into 3.4.9
 version
 > release. I'm planning to start looking at the jira issues
 currently
 > marked
 > for 3.4.9 and move into 3.4.10. I'd like to propose a
 deadline,
 > sometime
 > around *Tuesday, 16 August 2016 PST* to hear from you. Kindly
 > requesting
 > everyone to look at the open jira issues marked for 3.4.9 and
 let me
 > know
 > your thoughts asap. Thanks!
 >
 > I personally feel, only ZOOKEEPER-2383 blocker could be good
 candidate
 > for
 > this version. Please feel free to add your inputs and help me
 to take a
 > decision for this jira.
 >
 > Please find the open issues here, https://goo.gl/SEliwm
 >
 > Thanks,
 > Rakesh
 >
 > On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan <
 > rake...@apache.org>
 > wrote:
 >
 > > Hi All,
 > >
 > > (1) ZK-2383 -> Attached patch and the bug reporter has shown
 > interests to
 > > review/test the available patch. @Flavio, @Patrick, do you
 have some
 > cycles
 > > to review the proposed patch. Welcome others input as well.
 Thanks!
 > >
 > > (2) I believe we are very close to finish ZK-2247, waiting
 for the
 > final
 > > reviews and commit.
 > >
 > > (3) I'd love to include ZK-2355 also. It looks like the fix
 is good,
 > I've
 > > added few comments. Perhaps, will wait to see feedback from
 others.
 > >
 > > Kindly requesting everyone to look at your issues marked
 for 3.4.9
 > and
 > > push these asap or can be pushed out to 3.4.10.
 > >
 > > Thanks,
 > > Rakesh
 > >
 > > On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt <
 ph...@apache.org>
 > wrote:
 > >
 > >> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
 > >> 

Re: ZooKeeper 3.4.9 release discussion

[Rakesh Radhakrishnan]

It seems,
https://github.com/apache/zookeeper/blob/branch-3.4/docs/releasenotes.html
beginning with "ZooKeeper 3.4.5 Release Notes". I hope I need to append the
details of 3.4.6, 3.4.7, 3.4.8 first and then add our current 3.4.9 release
notes, isn't it?


Thanks,
Rakesh

On Wed, Aug 17, 2016 at 8:13 AM, Rakesh Radhakrishnan 
wrote:

> Thanks Patrick and Chris for quickly resolving this. I will continue with
> the release procedures.
>
> Rakesh
>
> On Wed, Aug 17, 2016 at 4:50 AM, Patrick Hunt  wrote:
>
>> Great, thanks Chris!
>>
>> Patrick
>>
>> On Tue, Aug 16, 2016 at 4:16 PM, Chris Nauroth 
>> wrote:
>>
>>> I just committed the ZOOKEEPER-2514 patch.  Patrick, thank you for the
>>> quick turnaround.  Rakesh, I think you’re all set to proceed with release
>>> notes for the 3.4.9 release candidate.
>>>
>>> --Chris Nauroth
>>>
>>> On 8/16/16, 2:52 PM, "Patrick Hunt"  wrote:
>>>
>>> Rakesh pointed out that the current "how to release" docs no longer
>>> are
>>> correct for branch-3.4 as in branch-3.5 and later we updated the
>>> release
>>> notes creation process to simplify it. Used to be very manual, in
>>> 3.5+ we
>>> moved to using the HTML available from Jira. I've created the
>>> following
>>> JIRA to backport that change to branch 3.4. After this patch is
>>> applied the
>>> RM process for release notes creation in 3.4 is consistent with the
>>> "how to
>>> release" documentation available on the wiki.
>>>
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2514
>>>
>>> Chris would you be able to take a look/review as well? That would
>>> help to
>>> unstick Rakesh with 3.4.9 (although he can review/commit as well but
>>> given
>>> the timezone diff...)
>>>
>>> Thanks,
>>>
>>> Patrick
>>>
>>>
>>> On Tue, Aug 16, 2016 at 10:55 AM, Chris Nauroth <
>>> cnaur...@hortonworks.com>
>>> wrote:
>>>
>>> > +1 for the plan.  Rakesh, thank you for working on the 3.4.9
>>> release.
>>> >
>>> > --Chris Nauroth
>>> >
>>> > On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan" 
>>> wrote:
>>> >
>>> > Hi All,
>>> >
>>> > I think we have given enough time to push issues into 3.4.9
>>> version
>>> > release. I'm planning to start looking at the jira issues
>>> currently
>>> > marked
>>> > for 3.4.9 and move into 3.4.10. I'd like to propose a deadline,
>>> > sometime
>>> > around *Tuesday, 16 August 2016 PST* to hear from you. Kindly
>>> > requesting
>>> > everyone to look at the open jira issues marked for 3.4.9 and
>>> let me
>>> > know
>>> > your thoughts asap. Thanks!
>>> >
>>> > I personally feel, only ZOOKEEPER-2383 blocker could be good
>>> candidate
>>> > for
>>> > this version. Please feel free to add your inputs and help me
>>> to take a
>>> > decision for this jira.
>>> >
>>> > Please find the open issues here, https://goo.gl/SEliwm
>>> >
>>> > Thanks,
>>> > Rakesh
>>> >
>>> > On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan <
>>> > rake...@apache.org>
>>> > wrote:
>>> >
>>> > > Hi All,
>>> > >
>>> > > (1) ZK-2383 -> Attached patch and the bug reporter has shown
>>> > interests to
>>> > > review/test the available patch. @Flavio, @Patrick, do you
>>> have some
>>> > cycles
>>> > > to review the proposed patch. Welcome others input as well.
>>> Thanks!
>>> > >
>>> > > (2) I believe we are very close to finish ZK-2247, waiting
>>> for the
>>> > final
>>> > > reviews and commit.
>>> > >
>>> > > (3) I'd love to include ZK-2355 also. It looks like the fix
>>> is good,
>>> > I've
>>> > > added few comments. Perhaps, will wait to see feedback from
>>> others.
>>> > >
>>> > > Kindly requesting everyone to look at your issues marked for
>>> 3.4.9
>>> > and
>>> > > push these asap or can be pushed out to 3.4.10.
>>> > >
>>> > > Thanks,
>>> > > Rakesh
>>> > >
>>> > > On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt <
>>> ph...@apache.org>
>>> > wrote:
>>> > >
>>> > >> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
>>> > >>  wrote:
>>> > >> >
>>> > >> > >ZK-1045 is a major change and I suggest we give time
>>> for
>>> > folks to
>>> > >> try
>>> > >> > it out before cutting a release candidate. Ideally, we
>>> check it
>>> > in and
>>> > >> give
>>> > >> > a few weeks until we cut a release candidate.
>>> > >> >
>>> > >> > Agreed, will try to push ZK-1045 in asap. Michael and
>>> myself is
>>> > working
>>> > >> > closely to finish the following set of open points.
>>> 

Re: ZooKeeper 3.4.9 release discussion

[Rakesh Radhakrishnan]

Thanks Patrick and Chris for quickly resolving this. I will continue with
the release procedures.

Rakesh

On Wed, Aug 17, 2016 at 4:50 AM, Patrick Hunt  wrote:

> Great, thanks Chris!
>
> Patrick
>
> On Tue, Aug 16, 2016 at 4:16 PM, Chris Nauroth 
> wrote:
>
>> I just committed the ZOOKEEPER-2514 patch.  Patrick, thank you for the
>> quick turnaround.  Rakesh, I think you’re all set to proceed with release
>> notes for the 3.4.9 release candidate.
>>
>> --Chris Nauroth
>>
>> On 8/16/16, 2:52 PM, "Patrick Hunt"  wrote:
>>
>> Rakesh pointed out that the current "how to release" docs no longer
>> are
>> correct for branch-3.4 as in branch-3.5 and later we updated the
>> release
>> notes creation process to simplify it. Used to be very manual, in
>> 3.5+ we
>> moved to using the HTML available from Jira. I've created the
>> following
>> JIRA to backport that change to branch 3.4. After this patch is
>> applied the
>> RM process for release notes creation in 3.4 is consistent with the
>> "how to
>> release" documentation available on the wiki.
>>
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2514
>>
>> Chris would you be able to take a look/review as well? That would
>> help to
>> unstick Rakesh with 3.4.9 (although he can review/commit as well but
>> given
>> the timezone diff...)
>>
>> Thanks,
>>
>> Patrick
>>
>>
>> On Tue, Aug 16, 2016 at 10:55 AM, Chris Nauroth <
>> cnaur...@hortonworks.com>
>> wrote:
>>
>> > +1 for the plan.  Rakesh, thank you for working on the 3.4.9
>> release.
>> >
>> > --Chris Nauroth
>> >
>> > On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan" 
>> wrote:
>> >
>> > Hi All,
>> >
>> > I think we have given enough time to push issues into 3.4.9
>> version
>> > release. I'm planning to start looking at the jira issues
>> currently
>> > marked
>> > for 3.4.9 and move into 3.4.10. I'd like to propose a deadline,
>> > sometime
>> > around *Tuesday, 16 August 2016 PST* to hear from you. Kindly
>> > requesting
>> > everyone to look at the open jira issues marked for 3.4.9 and
>> let me
>> > know
>> > your thoughts asap. Thanks!
>> >
>> > I personally feel, only ZOOKEEPER-2383 blocker could be good
>> candidate
>> > for
>> > this version. Please feel free to add your inputs and help me
>> to take a
>> > decision for this jira.
>> >
>> > Please find the open issues here, https://goo.gl/SEliwm
>> >
>> > Thanks,
>> > Rakesh
>> >
>> > On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan <
>> > rake...@apache.org>
>> > wrote:
>> >
>> > > Hi All,
>> > >
>> > > (1) ZK-2383 -> Attached patch and the bug reporter has shown
>> > interests to
>> > > review/test the available patch. @Flavio, @Patrick, do you
>> have some
>> > cycles
>> > > to review the proposed patch. Welcome others input as well.
>> Thanks!
>> > >
>> > > (2) I believe we are very close to finish ZK-2247, waiting
>> for the
>> > final
>> > > reviews and commit.
>> > >
>> > > (3) I'd love to include ZK-2355 also. It looks like the fix
>> is good,
>> > I've
>> > > added few comments. Perhaps, will wait to see feedback from
>> others.
>> > >
>> > > Kindly requesting everyone to look at your issues marked for
>> 3.4.9
>> > and
>> > > push these asap or can be pushed out to 3.4.10.
>> > >
>> > > Thanks,
>> > > Rakesh
>> > >
>> > > On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt <
>> ph...@apache.org>
>> > wrote:
>> > >
>> > >> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
>> > >>  wrote:
>> > >> >
>> > >> > >ZK-1045 is a major change and I suggest we give time
>> for
>> > folks to
>> > >> try
>> > >> > it out before cutting a release candidate. Ideally, we
>> check it
>> > in and
>> > >> give
>> > >> > a few weeks until we cut a release candidate.
>> > >> >
>> > >> > Agreed, will try to push ZK-1045 in asap. Michael and
>> myself is
>> > working
>> > >> > closely to finish the following set of open points.
>> Hopefully by
>> > next
>> > >> week
>> > >> > we will be able to complete the identified tasks, then
>> will post
>> > updated
>> > >> > patch and test report. I would appreciate review
>> > >> > comments/questions/feedback from others.
>> > >> >
>> > >>
>> > >> I am taking another pass at this next.
>> > >>
>> > >> > Pending tasks:-
>> > >> > 1) support authorization in sasl.
>> > >> > 2) few minor log 

[jira] [Commented] (ZOOKEEPER-2505) Use shared library instead of static library in C client unit test

[Michael Han (JIRA)]

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

Michael Han commented on ZOOKEEPER-2505:


Hey [~cnauroth]: I set up a Solaris 10 system using Oracle Solaris 10 1/13 
VirtualBox Template[1] and installed tool chains for native code to build 
(autoconf, libtool, g++, automake, gmake) using opencws, but test-core-cppunit 
does not work out of box - the wrapper options were not passed to linker when 
test-core-cppunit is invoked so the tests complaining about missing those 
wrapper symbols. I am sure this is fixed by you in ZOOKEEPER-1077 (which is 
also verified by zk Solaris build), so I assume this must be a problem with my 
local system environment set up. I'll check it out more in detail. Once that is 
figured out, I can proceed to verify if shared lib works for c test on Solaris 
or not.

I am curious what's the spec of the Solaris OS you were using for dev in 
ZOOKEEPER-1077? 

[1] 
http://www.oracle.com/technetwork/server-storage/solaris11/vmtemplates-vmvirtualbox-1949721.html

> Use shared library instead of static library in C client unit test
> --
>
> Key: ZOOKEEPER-2505
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2505
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: c client
>Affects Versions: 3.5.2
>Reporter: Michael Han
>Assignee: Michael Han
>Priority: Minor
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2505.patch
>
>
> Currently we are statically linking c unit tests to ZK client library - we 
> should use shared library instead as there seems no particular reason to 
> stick to static library, plus one benefit of using shared library is that 
> would allow us to use overrides function calls from standard libraries at 
> link time so we can simulate the wrap option for ld linker on os x. 



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

ZooKeeper_branch34_jdk8 - Build # 670 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_jdk8/670/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 225803 lines...]
[junit] 2016-08-17 00:12:28,381 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-08-17 00:12:28,381 [myid:] - INFO  
[main:SyncRequestProcessor@208] - Shutting down
[junit] 2016-08-17 00:12:28,381 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-08-17 00:12:28,381 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@186] - SyncRequestProcessor exited!
[junit] 2016-08-17 00:12:28,382 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-08-17 00:12:28,383 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-08-17 00:12:28,383 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-08-17 00:12:28,384 [myid:] - INFO  [main:ClientBase@445] - 
STARTING server
[junit] 2016-08-17 00:12:28,385 [myid:] - INFO  [main:ClientBase@366] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-08-17 00:12:28,385 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-08-17 00:12:28,385 [myid:] - INFO  [main:ClientBase@341] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-08-17 00:12:28,385 [myid:] - INFO  [main:ZooKeeperServer@173] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/branch-3.4/build/test/tmp/test6857503280075937139.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/branch-3.4/build/test/tmp/test6857503280075937139.junit.dir/version-2
[junit] 2016-08-17 00:12:28,388 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-17 00:12:28,388 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-08-17 00:12:28,389 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:43976
[junit] 2016-08-17 00:12:28,389 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:43976
[junit] 2016-08-17 00:12:28,390 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-08-17 00:12:28,390 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:43976 (no session established for client)
[junit] 2016-08-17 00:12:28,390 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-08-17 00:12:28,392 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-08-17 00:12:28,392 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-08-17 00:12:28,392 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-08-17 00:12:28,392 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-08-17 00:12:28,393 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 33587
[junit] 2016-08-17 00:12:28,393 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-08-17 00:12:28,393 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-08-17 00:12:28,393 [myid:] - INFO  [main:ClientBase@522] - 
tearDown starting
[junit] 2016-08-17 00:12:28,465 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x15695d791cc closed
[junit] 2016-08-17 00:12:28,465 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x15695d791cc
[junit] 2016-08-17 00:12:28,465 [myid:] - INFO  [main:ClientBase@492] - 
STOPPING server
[junit] 2016-08-17 00:12:28,465 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-08-17 00:12:28,466 [myid:] - INFO  [main:ZooKeeperServer@497] 
- shutting down
[junit] 2016-08-17 00:12:28,466 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-17 00:12:28,466 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 

[jira] [Resolved] (ZOOKEEPER-2009) zkCli does not execute command passed as arguments

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro resolved ZOOKEEPER-2009.
---
Resolution: Duplicate

Another duplicate of ZOOKEEPER-1897 

> zkCli does not execute command passed as arguments
> --
>
> Key: ZOOKEEPER-2009
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2009
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Simon Cooper
>Priority: Minor
>  Labels: regression
>
> In 3.4.5, zkCli executed commands passed on the command line. This command 
> would create the {{/test}} znode and exit, with a non-zero exit code if the 
> command failed:
> {code}
> $ ./zkCli.sh create /test null
> {code}
> This is no longer the case in 3.4.6 - the command is not executed, but zkCli 
> still runs & exits with a zero exit code.
> The interim workaround in bash is to use here documents:
> {code}
> $ ./zkCli.sh < create /test null
> EOF
> {code}



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

ZooKeeper-trunk - Build # 3039 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk/3039/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 440870 lines...]
[junit] 2016-08-16 23:26:49,278 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x101edd972e5
[junit] 2016-08-16 23:26:49,278 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 204731
[junit] 2016-08-16 23:26:49,280 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 1640
[junit] 2016-08-16 23:26:49,280 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-08-16 23:26:49,280 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-08-16 23:26:49,280 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-08-16 23:26:49,280 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:19545
[junit] 2016-08-16 23:26:49,284 [myid:] - INFO  [main:ZooKeeperServer@529] 
- shutting down
[junit] 2016-08-16 23:26:49,285 [myid:] - ERROR [main:ZooKeeperServer@501] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 23:26:49,285 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-08-16 23:26:49,285 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-08-16 23:26:49,285 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-08-16 23:26:49,285 [myid:] - INFO  [ProcessThread(sid:0 
cport:19545)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-08-16 23:26:49,285 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-08-16 23:26:49,285 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-08-16 23:26:49,286 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port19545,name1=InMemoryDataTree]
[junit] 2016-08-16 23:26:49,286 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port19545]
[junit] 2016-08-16 23:26:49,286 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 19545
[junit] 2016-08-16 23:26:49,287 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-08-16 23:26:49,291 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 4823 at start it was 4823
[junit] 2016-08-16 23:26:49,291 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-08-16 23:26:49,291 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
408.073 sec, Thread: 4, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2016-08-16 23:26:49,426 [myid:127.0.0.1:19425] - INFO  
[main-SendThread(127.0.0.1:19425):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:19425. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-08-16 23:26:49,427 [myid:127.0.0.1:19425] - WARN  
[main-SendThread(127.0.0.1:19425):ClientCnxn$SendThread@1235] - Session 
0x201edd6a90d for server 127.0.0.1/127.0.0.1:19425, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-08-16 23:26:49,436 [myid:127.0.0.1:19428] - INFO  
[main-SendThread(127.0.0.1:19428):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:19428. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-08-16 23:26:49,436 [myid:127.0.0.1:19428] - WARN  
[main-SendThread(127.0.0.1:19428):ClientCnxn$SendThread@1235] - Session 
0x301edd6a910 for server 127.0.0.1/127.0.0.1:19428, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit]  

Re: ZooKeeper 3.4.9 release discussion

[Patrick Hunt]

Great, thanks Chris!

Patrick

On Tue, Aug 16, 2016 at 4:16 PM, Chris Nauroth 
wrote:

> I just committed the ZOOKEEPER-2514 patch.  Patrick, thank you for the
> quick turnaround.  Rakesh, I think you’re all set to proceed with release
> notes for the 3.4.9 release candidate.
>
> --Chris Nauroth
>
> On 8/16/16, 2:52 PM, "Patrick Hunt"  wrote:
>
> Rakesh pointed out that the current "how to release" docs no longer are
> correct for branch-3.4 as in branch-3.5 and later we updated the
> release
> notes creation process to simplify it. Used to be very manual, in 3.5+
> we
> moved to using the HTML available from Jira. I've created the following
> JIRA to backport that change to branch 3.4. After this patch is
> applied the
> RM process for release notes creation in 3.4 is consistent with the
> "how to
> release" documentation available on the wiki.
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2514
>
> Chris would you be able to take a look/review as well? That would help
> to
> unstick Rakesh with 3.4.9 (although he can review/commit as well but
> given
> the timezone diff...)
>
> Thanks,
>
> Patrick
>
>
> On Tue, Aug 16, 2016 at 10:55 AM, Chris Nauroth <
> cnaur...@hortonworks.com>
> wrote:
>
> > +1 for the plan.  Rakesh, thank you for working on the 3.4.9 release.
> >
> > --Chris Nauroth
> >
> > On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan" 
> wrote:
> >
> > Hi All,
> >
> > I think we have given enough time to push issues into 3.4.9
> version
> > release. I'm planning to start looking at the jira issues
> currently
> > marked
> > for 3.4.9 and move into 3.4.10. I'd like to propose a deadline,
> > sometime
> > around *Tuesday, 16 August 2016 PST* to hear from you. Kindly
> > requesting
> > everyone to look at the open jira issues marked for 3.4.9 and
> let me
> > know
> > your thoughts asap. Thanks!
> >
> > I personally feel, only ZOOKEEPER-2383 blocker could be good
> candidate
> > for
> > this version. Please feel free to add your inputs and help me to
> take a
> > decision for this jira.
> >
> > Please find the open issues here, https://goo.gl/SEliwm
> >
> > Thanks,
> > Rakesh
> >
> > On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan <
> > rake...@apache.org>
> > wrote:
> >
> > > Hi All,
> > >
> > > (1) ZK-2383 -> Attached patch and the bug reporter has shown
> > interests to
> > > review/test the available patch. @Flavio, @Patrick, do you
> have some
> > cycles
> > > to review the proposed patch. Welcome others input as well.
> Thanks!
> > >
> > > (2) I believe we are very close to finish ZK-2247, waiting for
> the
> > final
> > > reviews and commit.
> > >
> > > (3) I'd love to include ZK-2355 also. It looks like the fix is
> good,
> > I've
> > > added few comments. Perhaps, will wait to see feedback from
> others.
> > >
> > > Kindly requesting everyone to look at your issues marked for
> 3.4.9
> > and
> > > push these asap or can be pushed out to 3.4.10.
> > >
> > > Thanks,
> > > Rakesh
> > >
> > > On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt <
> ph...@apache.org>
> > wrote:
> > >
> > >> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
> > >>  wrote:
> > >> >
> > >> > >ZK-1045 is a major change and I suggest we give time
> for
> > folks to
> > >> try
> > >> > it out before cutting a release candidate. Ideally, we
> check it
> > in and
> > >> give
> > >> > a few weeks until we cut a release candidate.
> > >> >
> > >> > Agreed, will try to push ZK-1045 in asap. Michael and
> myself is
> > working
> > >> > closely to finish the following set of open points.
> Hopefully by
> > next
> > >> week
> > >> > we will be able to complete the identified tasks, then will
> post
> > updated
> > >> > patch and test report. I would appreciate review
> > >> > comments/questions/feedback from others.
> > >> >
> > >>
> > >> I am taking another pass at this next.
> > >>
> > >> > Pending tasks:-
> > >> > 1) support authorization in sasl.
> > >> > 2) few minor log improvements are open.
> > >> > 3) system testing and preparing report.
> > >> > 4) feature document with latest changes.
> > >> >
> > >> >
> > >> > >The other one, ZK-2383, needs work.
> > >> >
> > >> > Here, I'm planning to revert ZOOKEEPER-2026 committed code
> and
> > makes
>   

Re: ZooKeeper 3.4.9 release discussion

[Chris Nauroth]

I just committed the ZOOKEEPER-2514 patch.  Patrick, thank you for the quick 
turnaround.  Rakesh, I think you’re all set to proceed with release notes for 
the 3.4.9 release candidate.

--Chris Nauroth

On 8/16/16, 2:52 PM, "Patrick Hunt"  wrote:

Rakesh pointed out that the current "how to release" docs no longer are
correct for branch-3.4 as in branch-3.5 and later we updated the release
notes creation process to simplify it. Used to be very manual, in 3.5+ we
moved to using the HTML available from Jira. I've created the following
JIRA to backport that change to branch 3.4. After this patch is applied the
RM process for release notes creation in 3.4 is consistent with the "how to
release" documentation available on the wiki.

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

Chris would you be able to take a look/review as well? That would help to
unstick Rakesh with 3.4.9 (although he can review/commit as well but given
the timezone diff...)

Thanks,

Patrick


On Tue, Aug 16, 2016 at 10:55 AM, Chris Nauroth 
wrote:

> +1 for the plan.  Rakesh, thank you for working on the 3.4.9 release.
>
> --Chris Nauroth
>
> On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan"  wrote:
>
> Hi All,
>
> I think we have given enough time to push issues into 3.4.9 version
> release. I'm planning to start looking at the jira issues currently
> marked
> for 3.4.9 and move into 3.4.10. I'd like to propose a deadline,
> sometime
> around *Tuesday, 16 August 2016 PST* to hear from you. Kindly
> requesting
> everyone to look at the open jira issues marked for 3.4.9 and let me
> know
> your thoughts asap. Thanks!
>
> I personally feel, only ZOOKEEPER-2383 blocker could be good candidate
> for
> this version. Please feel free to add your inputs and help me to take 
a
> decision for this jira.
>
> Please find the open issues here, https://goo.gl/SEliwm
>
> Thanks,
> Rakesh
>
> On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan <
> rake...@apache.org>
> wrote:
>
> > Hi All,
> >
> > (1) ZK-2383 -> Attached patch and the bug reporter has shown
> interests to
> > review/test the available patch. @Flavio, @Patrick, do you have some
> cycles
> > to review the proposed patch. Welcome others input as well. Thanks!
> >
> > (2) I believe we are very close to finish ZK-2247, waiting for the
> final
> > reviews and commit.
> >
> > (3) I'd love to include ZK-2355 also. It looks like the fix is good,
> I've
> > added few comments. Perhaps, will wait to see feedback from others.
> >
> > Kindly requesting everyone to look at your issues marked for 3.4.9
> and
> > push these asap or can be pushed out to 3.4.10.
> >
> > Thanks,
> > Rakesh
> >
> > On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt 
> wrote:
> >
> >> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
> >>  wrote:
> >> >
> >> > >ZK-1045 is a major change and I suggest we give time for
> folks to
> >> try
> >> > it out before cutting a release candidate. Ideally, we check it
> in and
> >> give
> >> > a few weeks until we cut a release candidate.
> >> >
> >> > Agreed, will try to push ZK-1045 in asap. Michael and myself is
> working
> >> > closely to finish the following set of open points. Hopefully by
> next
> >> week
> >> > we will be able to complete the identified tasks, then will post
> updated
> >> > patch and test report. I would appreciate review
> >> > comments/questions/feedback from others.
> >> >
> >>
> >> I am taking another pass at this next.
> >>
> >> > Pending tasks:-
> >> > 1) support authorization in sasl.
> >> > 2) few minor log improvements are open.
> >> > 3) system testing and preparing report.
> >> > 4) feature document with latest changes.
> >> >
> >> >
> >> > >The other one, ZK-2383, needs work.
> >> >
> >> > Here, I'm planning to revert ZOOKEEPER-2026 committed code and
> makes
> >> this
> >> > issue open for discussion/fix. Does it sound good?
> >> >
> >>
> >> Given 2026 is already shipping I would be concerned about reverting
> it
> >> at this point. Why wouldn't we just fix the remaining issue(s)?
> >>
> >> Patrick
> >>
> >> > Thanks,
> >> > Rakesh
>  

[jira] [Commented] (ZOOKEEPER-2514) Simplify releasenotes creation for 3.4 branch - consistent with newer branches.

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-2514:
-

Great, thanks Chris!

> Simplify releasenotes creation for 3.4 branch - consistent with newer 
> branches.
> ---
>
> Key: ZOOKEEPER-2514
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2514
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.8
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
>Priority: Critical
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2514.patch
>
>
> ZOOKEEPER-2364 introduced a new process for creating release notes for 3.5 
> and later branches. Backport this to 3.4 branch in order to make the release 
> manager's life easier (and be consisten with "how to release" page).



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

[jira] [Resolved] (ZOOKEEPER-2514) Simplify releasenotes creation for 3.4 branch - consistent with newer branches.

[Chris Nauroth (JIRA)]

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

Chris Nauroth resolved ZOOKEEPER-2514.
--
  Resolution: Fixed
Assignee: Patrick Hunt  (was: Rakesh R)
Hadoop Flags: Reviewed

+1 for the patch.  I have committed this to branch-3.4.  [~phunt], thank you 
for the patch.

Cc [~rakeshr] for the 3.4.9 release.

> Simplify releasenotes creation for 3.4 branch - consistent with newer 
> branches.
> ---
>
> Key: ZOOKEEPER-2514
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2514
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.8
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
>Priority: Critical
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2514.patch
>
>
> ZOOKEEPER-2364 introduced a new process for creating release notes for 3.5 
> and later branches. Backport this to 3.4 branch in order to make the release 
> manager's life easier (and be consisten with "how to release" page).



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

ZooKeeper_branch34_jdk8 - Build # 669 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_jdk8/669/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 224702 lines...]
[junit] 2016-08-16 23:06:01,192 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-08-16 23:06:01,192 [myid:] - INFO  
[main:SyncRequestProcessor@208] - Shutting down
[junit] 2016-08-16 23:06:01,192 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-08-16 23:06:01,192 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@186] - SyncRequestProcessor exited!
[junit] 2016-08-16 23:06:01,193 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-08-16 23:06:01,194 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-08-16 23:06:01,195 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-08-16 23:06:01,196 [myid:] - INFO  [main:ClientBase@445] - 
STARTING server
[junit] 2016-08-16 23:06:01,197 [myid:] - INFO  [main:ClientBase@366] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-08-16 23:06:01,197 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-08-16 23:06:01,197 [myid:] - INFO  [main:ClientBase@341] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-08-16 23:06:01,198 [myid:] - INFO  [main:ZooKeeperServer@173] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/branch-3.4/build/test/tmp/test3195330687877966884.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/branch-3.4/build/test/tmp/test3195330687877966884.junit.dir/version-2
[junit] 2016-08-16 23:06:01,201 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 23:06:01,201 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-08-16 23:06:01,202 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:47631
[junit] 2016-08-16 23:06:01,202 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:47631
[junit] 2016-08-16 23:06:01,203 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-08-16 23:06:01,204 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:47631 (no session established for client)
[junit] 2016-08-16 23:06:01,204 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-08-16 23:06:01,206 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-08-16 23:06:01,206 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-08-16 23:06:01,206 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-08-16 23:06:01,206 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-08-16 23:06:01,207 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 33587
[junit] 2016-08-16 23:06:01,207 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-08-16 23:06:01,207 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-08-16 23:06:01,208 [myid:] - INFO  [main:ClientBase@522] - 
tearDown starting
[junit] 2016-08-16 23:06:01,275 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x156959abb00 closed
[junit] 2016-08-16 23:06:01,275 [myid:] - INFO  [main:ClientBase@492] - 
STOPPING server
[junit] 2016-08-16 23:06:01,275 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x156959abb00
[junit] 2016-08-16 23:06:01,276 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-08-16 23:06:01,276 [myid:] - INFO  [main:ZooKeeperServer@497] 
- shutting down
[junit] 2016-08-16 23:06:01,277 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 23:06:01,277 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 

Re: ZooKeeper 3.4.9 release discussion

[Patrick Hunt]

Rakesh pointed out that the current "how to release" docs no longer are
correct for branch-3.4 as in branch-3.5 and later we updated the release
notes creation process to simplify it. Used to be very manual, in 3.5+ we
moved to using the HTML available from Jira. I've created the following
JIRA to backport that change to branch 3.4. After this patch is applied the
RM process for release notes creation in 3.4 is consistent with the "how to
release" documentation available on the wiki.

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

Chris would you be able to take a look/review as well? That would help to
unstick Rakesh with 3.4.9 (although he can review/commit as well but given
the timezone diff...)

Thanks,

Patrick


On Tue, Aug 16, 2016 at 10:55 AM, Chris Nauroth 
wrote:

> +1 for the plan.  Rakesh, thank you for working on the 3.4.9 release.
>
> --Chris Nauroth
>
> On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan"  wrote:
>
> Hi All,
>
> I think we have given enough time to push issues into 3.4.9 version
> release. I'm planning to start looking at the jira issues currently
> marked
> for 3.4.9 and move into 3.4.10. I'd like to propose a deadline,
> sometime
> around *Tuesday, 16 August 2016 PST* to hear from you. Kindly
> requesting
> everyone to look at the open jira issues marked for 3.4.9 and let me
> know
> your thoughts asap. Thanks!
>
> I personally feel, only ZOOKEEPER-2383 blocker could be good candidate
> for
> this version. Please feel free to add your inputs and help me to take a
> decision for this jira.
>
> Please find the open issues here, https://goo.gl/SEliwm
>
> Thanks,
> Rakesh
>
> On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan <
> rake...@apache.org>
> wrote:
>
> > Hi All,
> >
> > (1) ZK-2383 -> Attached patch and the bug reporter has shown
> interests to
> > review/test the available patch. @Flavio, @Patrick, do you have some
> cycles
> > to review the proposed patch. Welcome others input as well. Thanks!
> >
> > (2) I believe we are very close to finish ZK-2247, waiting for the
> final
> > reviews and commit.
> >
> > (3) I'd love to include ZK-2355 also. It looks like the fix is good,
> I've
> > added few comments. Perhaps, will wait to see feedback from others.
> >
> > Kindly requesting everyone to look at your issues marked for 3.4.9
> and
> > push these asap or can be pushed out to 3.4.10.
> >
> > Thanks,
> > Rakesh
> >
> > On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt 
> wrote:
> >
> >> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
> >>  wrote:
> >> >
> >> > >ZK-1045 is a major change and I suggest we give time for
> folks to
> >> try
> >> > it out before cutting a release candidate. Ideally, we check it
> in and
> >> give
> >> > a few weeks until we cut a release candidate.
> >> >
> >> > Agreed, will try to push ZK-1045 in asap. Michael and myself is
> working
> >> > closely to finish the following set of open points. Hopefully by
> next
> >> week
> >> > we will be able to complete the identified tasks, then will post
> updated
> >> > patch and test report. I would appreciate review
> >> > comments/questions/feedback from others.
> >> >
> >>
> >> I am taking another pass at this next.
> >>
> >> > Pending tasks:-
> >> > 1) support authorization in sasl.
> >> > 2) few minor log improvements are open.
> >> > 3) system testing and preparing report.
> >> > 4) feature document with latest changes.
> >> >
> >> >
> >> > >The other one, ZK-2383, needs work.
> >> >
> >> > Here, I'm planning to revert ZOOKEEPER-2026 committed code and
> makes
> >> this
> >> > issue open for discussion/fix. Does it sound good?
> >> >
> >>
> >> Given 2026 is already shipping I would be concerned about reverting
> it
> >> at this point. Why wouldn't we just fix the remaining issue(s)?
> >>
> >> Patrick
> >>
> >> > Thanks,
> >> > Rakesh
> >> >
> >> > On Thu, Jul 7, 2016 at 6:51 PM, Flavio Junqueira 
> >> wrote:
> >> >
> >> > > Thanks for bootstrapping the release process for 3.4.9. ZK-1045
> is a
> >> major
> >> > > change and I suggest we give time for folks to try it out before
> >> cutting a
> >> > > release candidate. Ideally, we check it in and give a few weeks
> until
> >> we
> >> > > cut a release candidate.
> >> > >
> >> > > One of the blockers, ZK-2314 has only one remaining task which
> is to
> >> > > document missing SASL properties, so that should be easy. The
> other
> >> one,
> >> > > ZK-2383, needs work.
> >> > >
> >> > > Folks should check the remaining issues to determine if there
> is any
> >> other

[jira] [Commented] (ZOOKEEPER-2514) Simplify releasenotes creation for 3.4 branch - consistent with newer branches.

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-2514:
-

[~cnauroth] can you review this patch given you worked with me to address 
similar in ZOOKEEPER-2364. Thanks.

> Simplify releasenotes creation for 3.4 branch - consistent with newer 
> branches.
> ---
>
> Key: ZOOKEEPER-2514
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2514
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.8
>Reporter: Patrick Hunt
>Assignee: Rakesh R
>Priority: Critical
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2514.patch
>
>
> ZOOKEEPER-2364 introduced a new process for creating release notes for 3.5 
> and later branches. Backport this to 3.4 branch in order to make the release 
> manager's life easier (and be consisten with "how to release" page).



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

[jira] [Updated] (ZOOKEEPER-2514) Simplify releasenotes creation for 3.4 branch - consistent with newer branches.

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2514:

Attachment: ZOOKEEPER-2514.patch

This patch will only apply to 3.4 branch (hadoopqa bot will likely fail).

When you commit this patch please insure that you see the following changes:

deleted:docs/releasenotes.pdf
modified:   src/docs/forrest.properties
new file:   src/docs/src/documentation/conf/cli.xconf
deleted:src/docs/src/documentation/content/xdocs/releasenotes.xml

I ran the docs build and it passed for me with this patch applied.

> Simplify releasenotes creation for 3.4 branch - consistent with newer 
> branches.
> ---
>
> Key: ZOOKEEPER-2514
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2514
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.8
>Reporter: Patrick Hunt
>Assignee: Rakesh R
>Priority: Critical
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2514.patch
>
>
> ZOOKEEPER-2364 introduced a new process for creating release notes for 3.5 
> and later branches. Backport this to 3.4 branch in order to make the release 
> manager's life easier (and be consisten with "how to release" page).



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

[jira] [Created] (ZOOKEEPER-2514) Simplify releasenotes creation for 3.4 branch - consistent with newer branches.

[Patrick Hunt (JIRA)]

Patrick Hunt created ZOOKEEPER-2514:
---

 Summary: Simplify releasenotes creation for 3.4 branch - 
consistent with newer branches.
 Key: ZOOKEEPER-2514
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2514
 Project: ZooKeeper
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.4.8
Reporter: Patrick Hunt
Assignee: Rakesh R
Priority: Critical
 Fix For: 3.4.9


ZOOKEEPER-2364 introduced a new process for creating release notes for 3.5 and 
later branches. Backport this to 3.4 branch in order to make the release 
manager's life easier (and be consisten with "how to release" page).



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

ZooKeeper-trunk-openjdk7 - Build # 1130 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/1130/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 447529 lines...]
[junit] 2016-08-16 21:05:42,302 [myid:] - INFO  [main:ClientBase@466] - 
STARTING server
[junit] 2016-08-16 21:05:42,302 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-08-16 21:05:42,302 [myid:] - INFO  
[main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 3 selector thread(s), 48 worker threads, and 64 
kB direct buffers.
[junit] 2016-08-16 21:05:42,303 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-08-16 21:05:42,303 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-08-16 21:05:42,303 [myid:] - INFO  [main:ZooKeeperServer@889] 
- minSessionTimeout set to 6000
[junit] 2016-08-16 21:05:42,303 [myid:] - INFO  [main:ZooKeeperServer@898] 
- maxSessionTimeout set to 6
[junit] 2016-08-16 21:05:42,304 [myid:] - INFO  [main:ZooKeeperServer@159] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test8359400587908924892.junit.dir/version-2
 snapdir 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test8359400587908924892.junit.dir/version-2
[junit] 2016-08-16 21:05:42,305 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test8359400587908924892.junit.dir/version-2/snapshot.b
[junit] 2016-08-16 21:05:42,307 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test8359400587908924892.junit.dir/version-2/snapshot.b
[junit] 2016-08-16 21:05:42,309 [myid:] - ERROR [main:ZooKeeperServer@501] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 21:05:42,309 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-08-16 21:05:42,309 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:50846
[junit] 2016-08-16 21:05:42,310 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:50846
[junit] 2016-08-16 21:05:42,310 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-08-16 21:05:42,310 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:50846 (no session established for client)
[junit] 2016-08-16 21:05:42,311 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-08-16 21:05:42,312 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-08-16 21:05:42,312 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-08-16 21:05:42,313 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-08-16 21:05:42,313 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-08-16 21:05:42,313 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 70288
[junit] 2016-08-16 21:05:42,313 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 25
[junit] 2016-08-16 21:05:42,313 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-08-16 21:05:42,313 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-08-16 21:05:42,382 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1004e0b703b closed
[junit] 2016-08-16 21:05:42,382 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-08-16 21:05:42,383 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-08-16 21:05:42,383 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-08-16 21:05:42,383 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-08-16 21:05:42,385 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] 

Seems Reddit is using ZK.

[Patrick Hunt]

Unfortunate incident, some ops issues while migrating ZK/infra led to site
outage. Sheds some light on how Reddit uses ZK though:

"We use a system called Zookeeper to keep track of most of our servers and
their health."

https://www.reddit.com/r/announcements/comments/4y0m56/why_reddit_was_down_on_aug_11/

Patrick

Re: ZOOKEEPER pre-commit fails if patch contains binary file

[Chris Nauroth]

The last time we discussed this, consensus in the community was that our most 
effective roadmap for build toolchain improvements would be:

1) Migrate to Maven.  This is tracked in ZOOKEEPER-1078, and I know you’re 
interested in pushing that one ahead too.
2) Migrate to Yetus after the switch to Maven.

I don’t believe there is anything we are waiting on from the Yetus project in 
terms of features or stability.  It’s already used successfully in Hadoop and 
other projects.  Yetus can work with an Ant build, but our integration with 
Yetus would look different for an Ant build vs. a Maven build.  If Maven 
migration is inevitable, then I’d rather not spend effort on the Ant build 
integration only to throw it away later.

--Chris Nauroth

On 8/16/16, 11:29 AM, "Arshad Mohammad"  wrote:

Thanks Chris, for clarification and suggestion. I will submit the patch
without binary file.

Seems Yetus is very important and necessary for ZooKeeper and I have heard
many times in community discussion that a particular problem can be solved
with Yetus
Is there any plan for migration like in 3.5.3 or in other release? is there
anything we are waiting for, like more stable Yetus release etc.

-Arshad


On Tue, Aug 16, 2016 at 11:34 PM, Chris Nauroth 
wrote:

> Unfortunately, I don’t think it’s possible for the current ZooKeeper
> test-patch.sh to work with a binary file.  If we eventually migrate to
> Apache Yetus, then its version of pre-commit has the capability to run 
“git
> apply”, which can handle binary diffs generated by “git diff”.
>
> For ZOOKEEPER-1260, I think you’ll need to work through pre-commit by
> attaching an alternative version of the patch that omits the binary file.
> (It’s a JPEG for the docs, so omitting the file won’t harm test results.)
>
> --Chris Nauroth
>
> On 8/16/16, 1:29 AM, "Mohammad arshad"  wrote:
>
> Hello everyone
>
> In ZooKeeper pre-commit patch apply has failed for the patch
> ZOOKEEPER-1260-01.patch. This patch applies on trunk locally
> ZOOKEEPER-1260-01.patch contains a binary file. This patch is
> generated with "git diff --no-prefix --binary HEAD >
> ZOOKEEPER-1260-01.patch" command
> I think the binary file, in the patch, is the reason for failure in 
CI.
> any idea on how to give patch in zookeeper which has binary file?
>
> Thanks
> -Arshad
>
>
>

Re: ZOOKEEPER pre-commit fails if patch contains binary file

[Arshad Mohammad]

Thanks Chris, for clarification and suggestion. I will submit the patch
without binary file.

Seems Yetus is very important and necessary for ZooKeeper and I have heard
many times in community discussion that a particular problem can be solved
with Yetus
Is there any plan for migration like in 3.5.3 or in other release? is there
anything we are waiting for, like more stable Yetus release etc.

-Arshad


On Tue, Aug 16, 2016 at 11:34 PM, Chris Nauroth 
wrote:

> Unfortunately, I don’t think it’s possible for the current ZooKeeper
> test-patch.sh to work with a binary file.  If we eventually migrate to
> Apache Yetus, then its version of pre-commit has the capability to run “git
> apply”, which can handle binary diffs generated by “git diff”.
>
> For ZOOKEEPER-1260, I think you’ll need to work through pre-commit by
> attaching an alternative version of the patch that omits the binary file.
> (It’s a JPEG for the docs, so omitting the file won’t harm test results.)
>
> --Chris Nauroth
>
> On 8/16/16, 1:29 AM, "Mohammad arshad"  wrote:
>
> Hello everyone
>
> In ZooKeeper pre-commit patch apply has failed for the patch
> ZOOKEEPER-1260-01.patch. This patch applies on trunk locally
> ZOOKEEPER-1260-01.patch contains a binary file. This patch is
> generated with "git diff --no-prefix --binary HEAD >
> ZOOKEEPER-1260-01.patch" command
> I think the binary file, in the patch, is the reason for failure in CI.
> any idea on how to give patch in zookeeper which has binary file?
>
> Thanks
> -Arshad
>
>
>

Re: http://zookeeper.apache.org/doc/r3.5.2-alpha/ showing old document

[Chris Nauroth]

I just updated the HowToRelease wiki and added this as step 3 under “Updating 
the release branch”.

--Chris Nauroth

On 8/16/16, 11:11 AM, "Patrick Hunt"  wrote:

I'm for it, couldn't hurt to have it as an explicit release mechanic.

Patrick

On Tue, Aug 16, 2016 at 10:58 AM, Chris Nauroth 
wrote:

> Arshad and Flavio, thank you for taking care of this.
>
> Currently, we have doc generation list in step 5 of the commit
> instructions [1], but it’s not part of the release process [2].  Shall we
> update the HowToRelease wiki to include a “final pass” doc re-generation,
> so that we catch anything that might have been missed on an earlier 
commit?
>
> [1] https://cwiki.apache.org/confluence/display/ZOOKEEPER/Commit
> ting+changes
> [2] https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
>
> --Chris Nauroth
>
> On 8/12/16, 10:04 AM, "Arshad Mohammad" 
> wrote:
>
> Thanks Flavio. I visited the site http://zookeeper.apache.org/
> doc/r3.5.2-alpha/ just now. It is showing the latest document.
>
> -Arshad
>
> On Fri, Aug 12, 2016 at 10:21 PM, Flavio Junqueira 
> wrote:
>
> > I've fixed this. Let me know if there is anything else I missed,
> please.
> >
> > -Flavio
> >
> > > On 10 Aug 2016, at 15:24, Flavio Junqueira  
wrote:
> > >
> > > I thought we were generating the new documentation upon releasing.
> I
> > just checked the how to release and we are just copying. I'll take
> care of
> > it.
> > >
> > > -Flavio
> > >
> > >> On 10 Aug 2016, at 07:52, Mohammad arshad <
> mohammad.ars...@huawei.com>
> > wrote:
> > >>
> > >> 1. I think it is ok to update the document, in the release tar,
> in the
> > next release
> > >> 2. Can we generate and update the documentation site
> > http://zookeeper.apache.org/doc/r3.5.2-alpha/, because mostly people
> > refer this website for document reference.
> > >>
> > >> -Arshad
> > >>
> > >> -Original Message-
> > >> From: Patrick Hunt [mailto:ph...@apache.org]
> > >> Sent: 10 August 2016 00:06
> > >> To: DevZooKeeper; Flavio
> > >> Subject: Re: http://zookeeper.apache.org/doc/r3.5.2-alpha/
> showing old
> > document
> > >>
> > >> Thanks for catching this Mohammad, it looks like this commit
> changed
> > the source on 3.5 branch but the generated docs were not
> re-generated:
> > >>
> > >> +  ZOOKEEPER-2402: Document client side properties (Arshad
> Mohammad via
> > >> + fpj)
> > >>
> > >> svn commit: r1745280 - in /zookeeper/branches/branch-3.5:
> CHANGES.txt
> > src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml
> > >> src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml
> > >>
> > >> As a result the published documentation is out of date with the
> source.
> > >>
> > >> We have a few options, including but not limited to: 1) fix it
> during
> > the next release (i.e. ignore it for now), 2) someone could
> regenerate the
> > documentation for that release and update the published docs
> manually.
> > >> others?
> > >>
> > >> Patrick
> > >>
> > >>
> > >> On Mon, Aug 8, 2016 at 8:24 AM, Mohammad arshad <
> > mohammad.ars...@huawei.com>
> > >> wrote:
> > >>
> > >>> http://zookeeper.apache.org/doc/r3.5.2-alpha/ is not showing the
> > >>> documentation which is released with zookeeper-3.5.2-alpha
> Released
> > >>> tar ball has up to date documentation source but the generated
> > >>> document is still old.
> > >>>
> > >>> For example:
> > >>> 
src\docs\src\documentation\content\xdocs\zookeeperProgrammers.xml
> has
> > >>> bellow content 
> > >>>  zookeeper.sasl.client
> > >>>  
> > >>> Set the value to  > >>> role="bold">false to disable
> > >>> SASL authentication. Default is
> > >>> true.
> > >>>  
> > >>> 
> > >>> But  generated document file docs/zookeeperProgrammers.html does
> not
> > >>> have above content.
> > >>>
> > >>> -Arshad
> > >>>
> > >>>
> > >
> >
> >
>
>
>

Re: [ANNOUNCE] Chris Nauroth joins the Apache ZooKeeper PMC

[Chris Nauroth]

Everyone, thank you very much for the invitation and the congrats.  I’m happy 
to be here!

--Chris Nauroth

On 8/7/16, 11:05 AM, "Flavio Junqueira"  wrote:

In recognition of all his contributions to the project, the Apache 
ZooKeeper PMC has invited Chris Nauroth to join the PMC and he has accepted. 
I'd like to take the opportunity to thank Chris for his contributions and 
commitment to the project. Thank you and congratulations for joining the PMC, 
Chris!

-Flavio

[jira] [Commented] (ZOOKEEPER-2491) C client build error in vs 2015

[Chris Nauroth (JIRA)]

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

Chris Nauroth commented on ZOOKEEPER-2491:
--

bq. copied from libuv.

If this code is a straight-up copy of libuv code, then we are required to 
acknowledge that project and its license in our NOTICE.txt file.

https://github.com/libuv/libuv/blob/v1.x/LICENSE

> C client build error in vs 2015 
> 
>
> Key: ZOOKEEPER-2491
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2491
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.2
> Environment: windows vs 2015
>Reporter: spooky000
>Assignee: spooky000
>Priority: Minor
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2491.patch, ZOOKEEPER-2491.patch, 
> ZOOKEEPER-2491.patch
>
>
> Visual Studio 2015  supports snprintf.
> #define snprintf _snprintf throw error.



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

[jira] [Commented] (ZOOKEEPER-2505) Use shared library instead of static library in C client unit test

[Michael Han (JIRA)]

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

Michael Han commented on ZOOKEEPER-2505:


[~cnauroth] Good point, I haven't tried the patch on Solaris. Will get a VM and 
test it out.

> Use shared library instead of static library in C client unit test
> --
>
> Key: ZOOKEEPER-2505
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2505
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: c client
>Affects Versions: 3.5.2
>Reporter: Michael Han
>Assignee: Michael Han
>Priority: Minor
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2505.patch
>
>
> Currently we are statically linking c unit tests to ZK client library - we 
> should use shared library instead as there seems no particular reason to 
> stick to static library, plus one benefit of using shared library is that 
> would allow us to use overrides function calls from standard libraries at 
> link time so we can simulate the wrap option for ld linker on os x. 



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

Re: http://zookeeper.apache.org/doc/r3.5.2-alpha/ showing old document

[Patrick Hunt]

I'm for it, couldn't hurt to have it as an explicit release mechanic.

Patrick

On Tue, Aug 16, 2016 at 10:58 AM, Chris Nauroth 
wrote:

> Arshad and Flavio, thank you for taking care of this.
>
> Currently, we have doc generation list in step 5 of the commit
> instructions [1], but it’s not part of the release process [2].  Shall we
> update the HowToRelease wiki to include a “final pass” doc re-generation,
> so that we catch anything that might have been missed on an earlier commit?
>
> [1] https://cwiki.apache.org/confluence/display/ZOOKEEPER/Commit
> ting+changes
> [2] https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease
>
> --Chris Nauroth
>
> On 8/12/16, 10:04 AM, "Arshad Mohammad" 
> wrote:
>
> Thanks Flavio. I visited the site http://zookeeper.apache.org/
> doc/r3.5.2-alpha/ just now. It is showing the latest document.
>
> -Arshad
>
> On Fri, Aug 12, 2016 at 10:21 PM, Flavio Junqueira 
> wrote:
>
> > I've fixed this. Let me know if there is anything else I missed,
> please.
> >
> > -Flavio
> >
> > > On 10 Aug 2016, at 15:24, Flavio Junqueira  wrote:
> > >
> > > I thought we were generating the new documentation upon releasing.
> I
> > just checked the how to release and we are just copying. I'll take
> care of
> > it.
> > >
> > > -Flavio
> > >
> > >> On 10 Aug 2016, at 07:52, Mohammad arshad <
> mohammad.ars...@huawei.com>
> > wrote:
> > >>
> > >> 1. I think it is ok to update the document, in the release tar,
> in the
> > next release
> > >> 2. Can we generate and update the documentation site
> > http://zookeeper.apache.org/doc/r3.5.2-alpha/, because mostly people
> > refer this website for document reference.
> > >>
> > >> -Arshad
> > >>
> > >> -Original Message-
> > >> From: Patrick Hunt [mailto:ph...@apache.org]
> > >> Sent: 10 August 2016 00:06
> > >> To: DevZooKeeper; Flavio
> > >> Subject: Re: http://zookeeper.apache.org/doc/r3.5.2-alpha/
> showing old
> > document
> > >>
> > >> Thanks for catching this Mohammad, it looks like this commit
> changed
> > the source on 3.5 branch but the generated docs were not
> re-generated:
> > >>
> > >> +  ZOOKEEPER-2402: Document client side properties (Arshad
> Mohammad via
> > >> + fpj)
> > >>
> > >> svn commit: r1745280 - in /zookeeper/branches/branch-3.5:
> CHANGES.txt
> > src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml
> > >> src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml
> > >>
> > >> As a result the published documentation is out of date with the
> source.
> > >>
> > >> We have a few options, including but not limited to: 1) fix it
> during
> > the next release (i.e. ignore it for now), 2) someone could
> regenerate the
> > documentation for that release and update the published docs
> manually.
> > >> others?
> > >>
> > >> Patrick
> > >>
> > >>
> > >> On Mon, Aug 8, 2016 at 8:24 AM, Mohammad arshad <
> > mohammad.ars...@huawei.com>
> > >> wrote:
> > >>
> > >>> http://zookeeper.apache.org/doc/r3.5.2-alpha/ is not showing the
> > >>> documentation which is released with zookeeper-3.5.2-alpha
> Released
> > >>> tar ball has up to date documentation source but the generated
> > >>> document is still old.
> > >>>
> > >>> For example:
> > >>> src\docs\src\documentation\content\xdocs\zookeeperProgrammers.xml
> has
> > >>> bellow content 
> > >>>  zookeeper.sasl.client
> > >>>  
> > >>> Set the value to  > >>> role="bold">false to disable
> > >>> SASL authentication. Default is
> > >>> true.
> > >>>  
> > >>> 
> > >>> But  generated document file docs/zookeeperProgrammers.html does
> not
> > >>> have above content.
> > >>>
> > >>> -Arshad
> > >>>
> > >>>
> > >
> >
> >
>
>
>

[jira] [Commented] (ZOOKEEPER-2505) Use shared library instead of static library in C client unit test

[Chris Nauroth (JIRA)]

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

Chris Nauroth commented on ZOOKEEPER-2505:
--

[~hanm], thank you for working on this.  I would love to get a complete build 
working on OS X too.

Have you tried this patch on a Solaris VM too?  Last time I checked, there were 
some finicky differences in linker flags on Solaris.

> Use shared library instead of static library in C client unit test
> --
>
> Key: ZOOKEEPER-2505
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2505
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: c client
>Affects Versions: 3.5.2
>Reporter: Michael Han
>Assignee: Michael Han
>Priority: Minor
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2505.patch
>
>
> Currently we are statically linking c unit tests to ZK client library - we 
> should use shared library instead as there seems no particular reason to 
> stick to static library, plus one benefit of using shared library is that 
> would allow us to use overrides function calls from standard libraries at 
> link time so we can simulate the wrap option for ld linker on os x. 



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

Re: ZOOKEEPER pre-commit fails if patch contains binary file

[Chris Nauroth]

Unfortunately, I don’t think it’s possible for the current ZooKeeper 
test-patch.sh to work with a binary file.  If we eventually migrate to Apache 
Yetus, then its version of pre-commit has the capability to run “git apply”, 
which can handle binary diffs generated by “git diff”.

For ZOOKEEPER-1260, I think you’ll need to work through pre-commit by attaching 
an alternative version of the patch that omits the binary file.  (It’s a JPEG 
for the docs, so omitting the file won’t harm test results.)

--Chris Nauroth

On 8/16/16, 1:29 AM, "Mohammad arshad"  wrote:

Hello everyone

In ZooKeeper pre-commit patch apply has failed for the patch 
ZOOKEEPER-1260-01.patch. This patch applies on trunk locally
ZOOKEEPER-1260-01.patch contains a binary file. This patch is generated 
with "git diff --no-prefix --binary HEAD > ZOOKEEPER-1260-01.patch" command
I think the binary file, in the patch, is the reason for failure in CI.
any idea on how to give patch in zookeeper which has binary file?

Thanks
-Arshad

Re: http://zookeeper.apache.org/doc/r3.5.2-alpha/ showing old document

[Chris Nauroth]

Arshad and Flavio, thank you for taking care of this.

Currently, we have doc generation list in step 5 of the commit instructions 
[1], but it’s not part of the release process [2].  Shall we update the 
HowToRelease wiki to include a “final pass” doc re-generation, so that we catch 
anything that might have been missed on an earlier commit?

[1] https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
[2] https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease

--Chris Nauroth

On 8/12/16, 10:04 AM, "Arshad Mohammad"  wrote:

Thanks Flavio. I visited the site http://zookeeper.apache.org/
doc/r3.5.2-alpha/ just now. It is showing the latest document.

-Arshad

On Fri, Aug 12, 2016 at 10:21 PM, Flavio Junqueira  wrote:

> I've fixed this. Let me know if there is anything else I missed, please.
>
> -Flavio
>
> > On 10 Aug 2016, at 15:24, Flavio Junqueira  wrote:
> >
> > I thought we were generating the new documentation upon releasing. I
> just checked the how to release and we are just copying. I'll take care of
> it.
> >
> > -Flavio
> >
> >> On 10 Aug 2016, at 07:52, Mohammad arshad 
> wrote:
> >>
> >> 1. I think it is ok to update the document, in the release tar, in the
> next release
> >> 2. Can we generate and update the documentation site
> http://zookeeper.apache.org/doc/r3.5.2-alpha/, because mostly people
> refer this website for document reference.
> >>
> >> -Arshad
> >>
> >> -Original Message-
> >> From: Patrick Hunt [mailto:ph...@apache.org]
> >> Sent: 10 August 2016 00:06
> >> To: DevZooKeeper; Flavio
> >> Subject: Re: http://zookeeper.apache.org/doc/r3.5.2-alpha/ showing old
> document
> >>
> >> Thanks for catching this Mohammad, it looks like this commit changed
> the source on 3.5 branch but the generated docs were not re-generated:
> >>
> >> +  ZOOKEEPER-2402: Document client side properties (Arshad Mohammad via
> >> + fpj)
> >>
> >> svn commit: r1745280 - in /zookeeper/branches/branch-3.5: CHANGES.txt
> src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml
> >> src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml
> >>
> >> As a result the published documentation is out of date with the source.
> >>
> >> We have a few options, including but not limited to: 1) fix it during
> the next release (i.e. ignore it for now), 2) someone could regenerate the
> documentation for that release and update the published docs manually.
> >> others?
> >>
> >> Patrick
> >>
> >>
> >> On Mon, Aug 8, 2016 at 8:24 AM, Mohammad arshad <
> mohammad.ars...@huawei.com>
> >> wrote:
> >>
> >>> http://zookeeper.apache.org/doc/r3.5.2-alpha/ is not showing the
> >>> documentation which is released with zookeeper-3.5.2-alpha Released
> >>> tar ball has up to date documentation source but the generated
> >>> document is still old.
> >>>
> >>> For example:
> >>> src\docs\src\documentation\content\xdocs\zookeeperProgrammers.xml has
> >>> bellow content 
> >>>  zookeeper.sasl.client
> >>>  
> >>> Set the value to  >>> role="bold">false to disable
> >>> SASL authentication. Default is
> >>> true.
> >>>  
> >>> 
> >>> But  generated document file docs/zookeeperProgrammers.html does not
> >>> have above content.
> >>>
> >>> -Arshad
> >>>
> >>>
> >
>
>

Re: ZooKeeper 3.4.9 release discussion

[Chris Nauroth]

+1 for the plan.  Rakesh, thank you for working on the 3.4.9 release.

--Chris Nauroth

On 8/15/16, 7:43 AM, "Rakesh Radhakrishnan"  wrote:

Hi All,

I think we have given enough time to push issues into 3.4.9 version
release. I'm planning to start looking at the jira issues currently marked
for 3.4.9 and move into 3.4.10. I'd like to propose a deadline, sometime
around *Tuesday, 16 August 2016 PST* to hear from you. Kindly requesting
everyone to look at the open jira issues marked for 3.4.9 and let me know
your thoughts asap. Thanks!

I personally feel, only ZOOKEEPER-2383 blocker could be good candidate for
this version. Please feel free to add your inputs and help me to take a
decision for this jira.

Please find the open issues here, https://goo.gl/SEliwm

Thanks,
Rakesh

On Sat, Jul 30, 2016 at 6:16 PM, Rakesh Radhakrishnan 
wrote:

> Hi All,
>
> (1) ZK-2383 -> Attached patch and the bug reporter has shown interests to
> review/test the available patch. @Flavio, @Patrick, do you have some 
cycles
> to review the proposed patch. Welcome others input as well. Thanks!
>
> (2) I believe we are very close to finish ZK-2247, waiting for the final
> reviews and commit.
>
> (3) I'd love to include ZK-2355 also. It looks like the fix is good, I've
> added few comments. Perhaps, will wait to see feedback from others.
>
> Kindly requesting everyone to look at your issues marked for 3.4.9 and
> push these asap or can be pushed out to 3.4.10.
>
> Thanks,
> Rakesh
>
> On Tue, Jul 19, 2016 at 2:49 AM, Patrick Hunt  wrote:
>
>> On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
>>  wrote:
>> >
>> > >ZK-1045 is a major change and I suggest we give time for folks to
>> try
>> > it out before cutting a release candidate. Ideally, we check it in and
>> give
>> > a few weeks until we cut a release candidate.
>> >
>> > Agreed, will try to push ZK-1045 in asap. Michael and myself is working
>> > closely to finish the following set of open points. Hopefully by next
>> week
>> > we will be able to complete the identified tasks, then will post 
updated
>> > patch and test report. I would appreciate review
>> > comments/questions/feedback from others.
>> >
>>
>> I am taking another pass at this next.
>>
>> > Pending tasks:-
>> > 1) support authorization in sasl.
>> > 2) few minor log improvements are open.
>> > 3) system testing and preparing report.
>> > 4) feature document with latest changes.
>> >
>> >
>> > >The other one, ZK-2383, needs work.
>> >
>> > Here, I'm planning to revert ZOOKEEPER-2026 committed code and makes
>> this
>> > issue open for discussion/fix. Does it sound good?
>> >
>>
>> Given 2026 is already shipping I would be concerned about reverting it
>> at this point. Why wouldn't we just fix the remaining issue(s)?
>>
>> Patrick
>>
>> > Thanks,
>> > Rakesh
>> >
>> > On Thu, Jul 7, 2016 at 6:51 PM, Flavio Junqueira 
>> wrote:
>> >
>> > > Thanks for bootstrapping the release process for 3.4.9. ZK-1045 is a
>> major
>> > > change and I suggest we give time for folks to try it out before
>> cutting a
>> > > release candidate. Ideally, we check it in and give a few weeks until
>> we
>> > > cut a release candidate.
>> > >
>> > > One of the blockers, ZK-2314 has only one remaining task which is to
>> > > document missing SASL properties, so that should be easy. The other
>> one,
>> > > ZK-2383, needs work.
>> > >
>> > > Folks should check the remaining issues to determine if there is any
>> other
>> > > blocker that we missed in that list.
>> > >
>> > > -Flavio
>> > >
>> > > > On 07 Jul 2016, at 05:12, Rakesh Radhakrishnan 
>> > > wrote:
>> > > >
>> > > > Hi All,
>> > > >
>> > > > I am interested in going through the release process as the RM.
>> > > >
>> > > > I could see total 23 issues marked for 3.4.9 release as of now,
>> which
>> > > > includes 2 blockers, 6 critical, 12 major and 3 minor issues. I
>> count 15
>> > > > issues fixed/committed already for 3.4.9 which includes 6 blockers
>> and 2
>> > > > critical(security related) issues. I think it is a good time to
>> initiate
>> > > > the discussion of 3.4.9 release processes.
>> > > >
>> > > > Please find the open issues here, https://goo.gl/SEliwm
>> > > >
>> > > > Currently, I'm focusing on ZOOKEEPER-1045 sasl feature which I
>> think is
>> > > > much appreciated/awaited feature and I'd like to include this if
>> everyone
>> > > > 

ZooKeeper_branch35_solaris - Build # 212 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_solaris/212/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 420942 lines...]
[junit] 2016-08-16 17:22:50,062 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-08-16 17:22:50,063 [myid:] - INFO  
[main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2016-08-16 17:22:50,063 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-08-16 17:22:50,064 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-08-16 17:22:50,064 [myid:] - INFO  [main:ZooKeeperServer@889] 
- minSessionTimeout set to 6000
[junit] 2016-08-16 17:22:50,065 [myid:] - INFO  [main:ZooKeeperServer@898] 
- maxSessionTimeout set to 6
[junit] 2016-08-16 17:22:50,065 [myid:] - INFO  [main:ZooKeeperServer@159] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test5329041218873960675.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test5329041218873960675.junit.dir/version-2
[junit] 2016-08-16 17:22:50,065 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test5329041218873960675.junit.dir/version-2/snapshot.b
[junit] 2016-08-16 17:22:50,067 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test5329041218873960675.junit.dir/version-2/snapshot.b
[junit] 2016-08-16 17:22:50,069 [myid:] - ERROR [main:ZooKeeperServer@501] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 17:22:50,069 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-08-16 17:22:50,069 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:53999
[junit] 2016-08-16 17:22:50,070 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:53999
[junit] 2016-08-16 17:22:50,070 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-08-16 17:22:50,070 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:53999 (no session established for client)
[junit] 2016-08-16 17:22:50,071 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-08-16 17:22:50,072 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-08-16 17:22:50,072 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-08-16 17:22:50,072 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-08-16 17:22:50,072 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-08-16 17:22:50,073 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17812
[junit] 2016-08-16 17:22:50,073 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-08-16 17:22:50,073 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-08-16 17:22:50,073 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-08-16 17:22:50,152 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x123115c56c0 closed
[junit] 2016-08-16 17:22:50,152 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x123115c56c0
[junit] 2016-08-16 17:22:50,152 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-08-16 17:22:50,152 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-08-16 17:22:50,152 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-08-16 17:22:50,152 [myid:] - INFO  

[jira] [Updated] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2383:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Assignee: Rakesh R
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java, 
> ZOOKEEPER-2383-br-3-4.patch, ZOOKEEPER-2383.patch, ZOOKEEPER-2383.patch, 
> ZOOKEEPER-2383.patch, release-3.4.8-extra-logging.patch, 
> zk-3.4.8-MBeanRegistry.log, zk-3.4.8-NPE.log
>
>
> In attempting to upgrade Solr's ZooKeeper dependency from 3.4.6 to 3.4.8 
> (SOLR-8724) I ran into test failures where attempts to create a node in a 
> newly started standalone ZooKeeperServer were failing because of an assertion 
> in MBeanRegistry.
> ZooKeeperServer.startup() first sets up its request processor chain then 
> registers itself in JMX, but if a connection comes in before the server's JMX 
> registration happens, registration of the connection will fail because it 
> trips the assertion that (effectively) its parent (the server) has already 
> registered itself.
> {code:java|title=ZooKeeperServer.java}
> public synchronized void startup() {
> if (sessionTracker == null) {
> createSessionTracker();
> }
> startSessionTracker();
> setupRequestProcessors();
> registerJMX();
> state = State.RUNNING;
> notifyAll();
> }
> {code}
> {code:java|title=MBeanRegistry.java}
> public void register(ZKMBeanInfo bean, ZKMBeanInfo parent)
> throws JMException
> {
> assert bean != null;
> String path = null;
> if (parent != null) {
> path = mapBean2Path.get(parent);
> assert path != null;
> }
> {code}
> This problem appears to be new with ZK 3.4.8 - AFAIK Solr never had this 
> issue with ZK 3.4.6. 



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

[jira] [Commented] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2355:
-

I am moving this out to 3.4.10 for now. Please feel free to discuss the target 
version, Thanks!

> Ephemeral node is never deleted if follower fails while reading the proposal 
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Martin Kuchta
>Priority: Critical
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch, 
> ZOOKEEPER-2355-03.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the 
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C, 
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with 
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario 
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with 
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created 
> is success.
> # Close the session,  ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have 
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}



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

[jira] [Updated] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2355:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Ephemeral node is never deleted if follower fails while reading the proposal 
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Martin Kuchta
>Priority: Critical
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch, 
> ZOOKEEPER-2355-03.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the 
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C, 
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with 
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario 
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with 
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created 
> is success.
> # Close the session,  ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have 
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}



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

[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2383:
-

I am moving this out to 3.4.10 for now. Please feel free to discuss the target 
version, Thanks!

> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Assignee: Rakesh R
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java, 
> ZOOKEEPER-2383-br-3-4.patch, ZOOKEEPER-2383.patch, ZOOKEEPER-2383.patch, 
> ZOOKEEPER-2383.patch, release-3.4.8-extra-logging.patch, 
> zk-3.4.8-MBeanRegistry.log, zk-3.4.8-NPE.log
>
>
> In attempting to upgrade Solr's ZooKeeper dependency from 3.4.6 to 3.4.8 
> (SOLR-8724) I ran into test failures where attempts to create a node in a 
> newly started standalone ZooKeeperServer were failing because of an assertion 
> in MBeanRegistry.
> ZooKeeperServer.startup() first sets up its request processor chain then 
> registers itself in JMX, but if a connection comes in before the server's JMX 
> registration happens, registration of the connection will fail because it 
> trips the assertion that (effectively) its parent (the server) has already 
> registered itself.
> {code:java|title=ZooKeeperServer.java}
> public synchronized void startup() {
> if (sessionTracker == null) {
> createSessionTracker();
> }
> startSessionTracker();
> setupRequestProcessors();
> registerJMX();
> state = State.RUNNING;
> notifyAll();
> }
> {code}
> {code:java|title=MBeanRegistry.java}
> public void register(ZKMBeanInfo bean, ZKMBeanInfo parent)
> throws JMException
> {
> assert bean != null;
> String path = null;
> if (parent != null) {
> path = mapBean2Path.get(parent);
> assert path != null;
> }
> {code}
> This problem appears to be new with ZK 3.4.8 - AFAIK Solr never had this 
> issue with ZK 3.4.6. 



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

[jira] [Commented] (ZOOKEEPER-896) Improve client to support dynamic authentication schemes

[Botond Hejj (JIRA)]

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

Botond Hejj commented on ZOOKEEPER-896:
---

The logic in the callback is intentionally left simple. I don't add any 
authentication or authorization logic in this patch I just create an interface 
to create one. The callback logic is always specific to the authentication 
implementation. If for example kerberos auth would use this than it would 
contact kerberos infra to obtain a token for the specific host. For the server 
code 
I here assume that the token returned by the callback is actually sent to the 
server by the client code. Maybe I could add a test to test that ClientCnxn is 
actually processing the returned process correctly and sending that to the 
server. I don't see similar test for the regular auth testing case and the code 
is very simple and it is basically the same so I don't think it is too valuable.
Am I completely misunderstanding you or is this makes sense?

> Improve client to support dynamic authentication schemes
> 
>
> Key: ZOOKEEPER-896
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-896
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: c client, java client
>Reporter: Botond Hejj
>Assignee: Botond Hejj
> Fix For: 3.5.3, 3.6.0
>
> Attachments: NIOServerCnxn.patch, ZOOKEEPER-896.patch, 
> ZOOKEEPER-896.patch, ZOOKEEPER-896.patch, ZOOKEEPER-896.patch, 
> ZOOKEEPER-896.patch
>
>
> When we started exploring zookeeper for our requirements we found the 
> authentication mechanism is not flexible enough.
> We want to use kerberos for authentication but using the current API we ran 
> into a few problems. The idea is that we get a kerberos token on the client 
> side and than send that token to the server with a kerberos scheme. A server 
> side authentication plugin can use that token to authenticate the client and 
> also use the token for authorization.
> We ran into two problems with this approach:
> 1. A different kerberos token is needed for each different server that client 
> can connect to since kerberos uses mutual authentication. That means when the 
> client acquires this kerberos token it has to know which server it connects 
> to and generate the token according to that. The client currently can't 
> generate a token for a specific server. The token stored in the auth_info is 
> used for all the servers.
> 2. The kerberos token might have an expiry time so if the client loses the 
> connection to the server and than it tries to reconnect it should acquire a 
> new token. That is not possible currently since the token is stored in 
> auth_info and reused for every connection.
> The problem can be solved if we allow the client to register a callback for 
> authentication instead a static token. This can be a callback with an 
> argument which passes the current host string. The zookeeper client code 
> could call this callback before it sends the authentication info to the 
> server to get a fresh server specific token.
> This would solve our problem with the kerberos authentication and also could 
> be used for other more dynamic authentication schemes.



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

ZooKeeper_branch35_jdk8 - Build # 194 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_jdk8/194/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 450848 lines...]
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-08-16 12:12:33,691 [myid:] - WARN  [New I/O boss 
#9405:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id: 
0x20479a2f] EXCEPTION: java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14036
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14036
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at 
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-08-16 12:12:33,700 [myid:] - INFO  [New I/O boss 
#9405:ClientCnxnSocketNetty@208] - channel is told closing
[junit] 2016-08-16 12:12:33,700 [myid:127.0.0.1:14036] - INFO  
[main-SendThread(127.0.0.1:14036):ClientCnxn$SendThread@1231] - channel for 
sessionid 0x10026c3bd8a is lost, closing socket connection and attempting 
reconnect
[junit] 2016-08-16 12:12:33,972 [myid:127.0.0.1:14039] - INFO  
[main-SendThread(127.0.0.1:14039):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:14039. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-08-16 12:12:33,973 [myid:] - INFO  [New I/O boss 
#9438:ClientCnxnSocketNetty$1@127] - future isn't success, cause: {}
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14039
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at 
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-08-16 12:12:33,974 [myid:] - WARN  [New I/O boss 
#9438:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id: 
0xacc52db0] EXCEPTION: java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14039
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14039
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at 

ZooKeeper-trunk-jdk8 - Build # 710 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-jdk8/710/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 453572 lines...]
[junit] 2016-08-16 11:58:28,326 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-08-16 11:58:28,326 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
521.377 sec, Thread: 4, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2016-08-16 11:58:28,558 [myid:127.0.0.1:19422] - INFO  
[main-SendThread(127.0.0.1:19422):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:19422. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-08-16 11:58:28,559 [myid:127.0.0.1:19422] - WARN  
[main-SendThread(127.0.0.1:19422):ClientCnxn$SendThread@1235] - Session 
0x1003d090407 for server 127.0.0.1/127.0.0.1:19422, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-08-16 11:59:23,492 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 128397
[junit] 2016-08-16 11:59:23,493 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 55
[junit] 2016-08-16 11:59:23,493 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testManyChildWatchersAutoReset
[junit] 2016-08-16 11:59:23,493 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-08-16 11:59:23,494 [myid:] - INFO  [ProcessThread(sid:0 
cport:16611)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x1003d028601
[junit] 2016-08-16 11:59:23,535 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1003d028601 closed
[junit] 2016-08-16 11:59:23,535 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1003d028601
[junit] 2016-08-16 11:59:23,535 [myid:] - INFO  
[NIOWorkerThread-26:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port16611,name1=Connections,name2=127.0.0.1,name3=0x1003d028601]
[junit] 2016-08-16 11:59:23,536 [myid:] - INFO  [ProcessThread(sid:0 
cport:16611)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x1003d0286010001
[junit] 2016-08-16 11:59:23,536 [myid:] - INFO  
[NIOWorkerThread-26:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:59495 which had sessionid 0x1003d028601
[junit] 2016-08-16 11:59:23,668 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1003d0286010001 closed
[junit] 2016-08-16 11:59:23,668 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1003d0286010001
[junit] 2016-08-16 11:59:23,668 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-08-16 11:59:23,668 [myid:] - INFO  
[NIOWorkerThread-12:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port16611,name1=Connections,name2=127.0.0.1,name3=0x1003d0286010001]
[junit] 2016-08-16 11:59:23,669 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-08-16 11:59:23,670 [myid:] - INFO  
[NIOWorkerThread-12:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:59465 which had sessionid 0x1003d0286010001
[junit] 2016-08-16 11:59:23,670 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:16611:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-08-16 11:59:23,672 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-08-16 11:59:23,674 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-08-16 11:59:23,677 [myid:] - INFO  [main:ZooKeeperServer@529] 
- shutting down
[junit] 2016-08-16 11:59:23,677 [myid:] - ERROR [main:ZooKeeperServer@501] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 11:59:23,677 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
 

[jira] [Updated] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-832:
---
Fix Version/s: (was: 3.4.9)
   3.4.10

> Invalid session id causes infinite loop during automatic reconnect
> --
>
> Key: ZOOKEEPER-832
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.5, 3.5.0
> Environment: All
>Reporter: Ryan Holmes
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch
>
>
> Steps to reproduce:
> 1.) Connect to a standalone server using the Java client.
> 2.) Stop the server.
> 3.) Delete the contents of the data directory (i.e. the persisted session 
> data).
> 4.) Start the server.
> The client now automatically tries to reconnect but the server refuses the 
> connection because the session id is invalid. The client and server are now 
> in an infinite loop of attempted and rejected connections. While this 
> situation represents a catastrophic failure and the current behavior is not 
> incorrect, it appears that there is no way to detect this situation on the 
> client and therefore no way to recover.
> The suggested improvement is to send an event to the default watcher 
> indicating that the current state is "session invalid", similar to how the 
> "session expired" state is handled.
> Server log output (repeats indefinitely):
> 2010-08-05 11:48:08,283 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - 
> Accepted socket connection from /127.0.0.1:63292
> 2010-08-05 11:48:08,284 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing 
> session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last 
> zxid is 0x0 client must try another server
> 2010-08-05 11:48:08,284 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed 
> socket connection for client /127.0.0.1:63292 (no session established for 
> client)
> Client log output (repeats indefinitely):
> 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - 
> Opening socket connection to server localhost/127.0.0.1:2181
> 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session 
> 0x12a3ae4e893000a for server null, unexpected error, closing socket 
> connection and attempting reconnect
> java.net.ConnectException: Connection refused
>   at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>   at 
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
> 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring 
> exception during shutdown input
> java.nio.channels.ClosedChannelException
>   at 
> sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638)
>   at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360)
>   at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)
> 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring 
> exception during shutdown output
> java.nio.channels.ClosedChannelException
>   at 
> sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649)
>   at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368)
>   at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)



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

[jira] [Commented] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-832:


I am moving this out to 3.4.10 for now. Hope, will be able to reach an 
agreement by that time.

> Invalid session id causes infinite loop during automatic reconnect
> --
>
> Key: ZOOKEEPER-832
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.5, 3.5.0
> Environment: All
>Reporter: Ryan Holmes
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch
>
>
> Steps to reproduce:
> 1.) Connect to a standalone server using the Java client.
> 2.) Stop the server.
> 3.) Delete the contents of the data directory (i.e. the persisted session 
> data).
> 4.) Start the server.
> The client now automatically tries to reconnect but the server refuses the 
> connection because the session id is invalid. The client and server are now 
> in an infinite loop of attempted and rejected connections. While this 
> situation represents a catastrophic failure and the current behavior is not 
> incorrect, it appears that there is no way to detect this situation on the 
> client and therefore no way to recover.
> The suggested improvement is to send an event to the default watcher 
> indicating that the current state is "session invalid", similar to how the 
> "session expired" state is handled.
> Server log output (repeats indefinitely):
> 2010-08-05 11:48:08,283 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - 
> Accepted socket connection from /127.0.0.1:63292
> 2010-08-05 11:48:08,284 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing 
> session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last 
> zxid is 0x0 client must try another server
> 2010-08-05 11:48:08,284 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed 
> socket connection for client /127.0.0.1:63292 (no session established for 
> client)
> Client log output (repeats indefinitely):
> 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - 
> Opening socket connection to server localhost/127.0.0.1:2181
> 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session 
> 0x12a3ae4e893000a for server null, unexpected error, closing socket 
> connection and attempting reconnect
> java.net.ConnectException: Connection refused
>   at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>   at 
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
> 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring 
> exception during shutdown input
> java.nio.channels.ClosedChannelException
>   at 
> sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638)
>   at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360)
>   at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)
> 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring 
> exception during shutdown output
> java.nio.channels.ClosedChannelException
>   at 
> sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649)
>   at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368)
>   at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)



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

[jira] [Updated] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2362:

Fix Version/s: (was: 3.4.9)
   3.4.10

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
> Fix For: 3.5.3, 3.4.10
>
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



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

[jira] [Commented] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2362:
-

I am moving this out to 3.4.10 for now. Hope this will get concluded by that 
time.

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
> Fix For: 3.5.3, 3.4.10
>
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



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

[jira] [Commented] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-1884:
-

I am moving this out to 3.4.10 for now. Please feel free to discuss the target 
version, if needed. Thanks!

> zkCli silently ignores commands with missing parameters
> ---
>
> Key: ZOOKEEPER-1884
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1884
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Flavio Junqueira
>Assignee: Raul Gutierrez Segales
>Priority: Minor
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-1884.patch
>
>
> Apparently, we have fixed this in trunk, but not in the 3.4 branch. When we 
> pass only the path to create, the command is not executed because it expects 
> an additional parameter and there is no error message because the create 
> command exists.



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

[jira] [Updated] (ZOOKEEPER-2440) permanent SESSIONMOVED error after client app reconnects to zookeeper cluster

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2440:

Fix Version/s: (was: 3.4.9)
   3.4.10

> permanent SESSIONMOVED error after client app reconnects to zookeeper cluster
> -
>
> Key: ZOOKEEPER-2440
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2440
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.5.0
>Reporter: Ryan Zhang
>Assignee: Ryan Zhang
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2440.patch
>
>
> ZOOKEEPER-710 fixed the issue when the request is not a multi request. 
> However, the multi request is handled a little bit differently as the code 
> didn't throw the SESSIONMOVED exception. In addition, the exception is set in 
> the request by the leader so it will be lost in the commit process and by the 
> time the final processor sees it, it will be gone. 



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

[jira] [Commented] (ZOOKEEPER-2440) permanent SESSIONMOVED error after client app reconnects to zookeeper cluster

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2440:
-

I am moving this out to 3.4.10 for now. Please feel free to discuss the target 
version, if needed. Thanks!

> permanent SESSIONMOVED error after client app reconnects to zookeeper cluster
> -
>
> Key: ZOOKEEPER-2440
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2440
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.5.0
>Reporter: Ryan Zhang
>Assignee: Ryan Zhang
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2440.patch
>
>
> ZOOKEEPER-710 fixed the issue when the request is not a multi request. 
> However, the multi request is handled a little bit differently as the code 
> didn't throw the SESSIONMOVED exception. In addition, the exception is set in 
> the request by the leader so it will be lost in the commit process and by the 
> time the final processor sees it, it will be gone. 



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

[jira] [Updated] (ZOOKEEPER-2154) NPE in KeeperException

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2154:

Fix Version/s: (was: 3.4.9)
   3.4.10

> NPE in KeeperException
> --
>
> Key: ZOOKEEPER-2154
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2154
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.6
>Reporter: Surendra Singh Lilhore
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2154.patch
>
>
> KeeperException should handle exception is code is null...



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

[jira] [Commented] (ZOOKEEPER-2314) Improvements to SASL

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2314:
-

I am moving this out to 3.4.10 for now. Please feel free to discuss the target 
version, if needed. Thanks!

> Improvements to SASL
> 
>
> Key: ZOOKEEPER-2314
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2314
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
>
> Points that occur to me right now:
> # The login object in ZooKeeperSaslClient is static, which means that if you 
> try to create another client for tests, the login object will be the first 
> one you've set for all runs. I've experienced this with 3.4.6.
> # There are a number of properties spread across the code that do not appear 
> in the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



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

[jira] [Commented] (ZOOKEEPER-2397) Undocumented SASL properties

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2397:
-

I am moving this out to 3.4.10 for now. Please feel free to discuss the target 
version, if needed. Thanks!

> Undocumented SASL properties
> 
>
> Key: ZOOKEEPER-2397
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2397
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2397.patch
>
>
> There are a number of properties spread across the code that do not appear in 
> the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



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

[jira] [Commented] (ZOOKEEPER-2154) NPE in KeeperException

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2154:
-

I am moving this out to 3.4.10 for now. [~surendrasingh], hope will be able 
sort out this.

> NPE in KeeperException
> --
>
> Key: ZOOKEEPER-2154
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2154
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.6
>Reporter: Surendra Singh Lilhore
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2154.patch
>
>
> KeeperException should handle exception is code is null...



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

[jira] [Updated] (ZOOKEEPER-2397) Undocumented SASL properties

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2397:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Undocumented SASL properties
> 
>
> Key: ZOOKEEPER-2397
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2397
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2397.patch
>
>
> There are a number of properties spread across the code that do not appear in 
> the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



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

[jira] [Updated] (ZOOKEEPER-2479) Add 'fleTimeTaken' value in LeaderMXBean and FollowerMXBean

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2479:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Add 'fleTimeTaken' value in LeaderMXBean and FollowerMXBean
> ---
>
> Key: ZOOKEEPER-2479
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2479
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: quorum
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2479.patch, ZOOKEEPER-2479.patch, 
> ZOOKEEPER-2479.patch, ZOOKEEPER-2479.patch
>
>
> The idea of this jira is to expose {{time taken}} for the leader election via 
> jmx Leader, Follower beans.



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

[jira] [Commented] (ZOOKEEPER-2184) Zookeeper Client should re-resolve hosts when connection attempts fail

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2184:
-

I am moving this out to 3.4.10 for now.

> Zookeeper Client should re-resolve hosts when connection attempts fail
> --
>
> Key: ZOOKEEPER-2184
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2184
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.6, 3.5.0
> Environment: Ubuntu 14.04 host, Docker containers for Zookeeper & 
> Kafka
>Reporter: Robert P. Thille
>Assignee: Robert P. Thille
>  Labels: easyfix, patch
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2184.patch
>
>
> Testing in a Docker environment with a single Kafka instance using a single 
> Zookeeper instance. Restarting the Zookeeper container will cause it to 
> receive a new IP address. Kafka will never be able to reconnect to Zookeeper 
> and will hang indefinitely. Updating DNS or /etc/hosts with the new IP 
> address will not help the client to reconnect as the 
> zookeeper/client/StaticHostProvider resolves the connection string hosts at 
> creation time and never re-resolves.
> A solution would be for the client to notice that connection attempts fail 
> and attempt to re-resolve the hostnames in the connectString.



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

[jira] [Updated] (ZOOKEEPER-2184) Zookeeper Client should re-resolve hosts when connection attempts fail

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2184:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Zookeeper Client should re-resolve hosts when connection attempts fail
> --
>
> Key: ZOOKEEPER-2184
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2184
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.6, 3.5.0
> Environment: Ubuntu 14.04 host, Docker containers for Zookeeper & 
> Kafka
>Reporter: Robert P. Thille
>Assignee: Robert P. Thille
>  Labels: easyfix, patch
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2184.patch
>
>
> Testing in a Docker environment with a single Kafka instance using a single 
> Zookeeper instance. Restarting the Zookeeper container will cause it to 
> receive a new IP address. Kafka will never be able to reconnect to Zookeeper 
> and will hang indefinitely. Updating DNS or /etc/hosts with the new IP 
> address will not help the client to reconnect as the 
> zookeeper/client/StaticHostProvider resolves the connection string hosts at 
> creation time and never re-resolves.
> A solution would be for the client to notice that connection attempts fail 
> and attempt to re-resolve the hostnames in the connectString.



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

[jira] [Commented] (ZOOKEEPER-2358) NettyServerCnxn leaks watches upon close

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2358:
-

I am moving this out to 3.4.10 for now. Please click {{Submit Patch}} button 
once ready for review. Thanks!

> NettyServerCnxn leaks watches upon close
> 
>
> Key: ZOOKEEPER-2358
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2358
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Ian Dimayuga
>Assignee: Ian Dimayuga
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2358-3.4.patch, ZOOKEEPER-2358.patch
>
>
> NettyServerCnxn.close() neglects to call zkServer.removeCnxn the way 
> NIOServerCnxn.close() does. Also, WatchLeakTest does not test watch leaks in 
> Netty.



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

[jira] [Updated] (ZOOKEEPER-2319) UnresolvedAddressException cause the QuorumCnxManager.Listener exit

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2319:

Fix Version/s: (was: 3.4.9)
   3.4.10

> UnresolvedAddressException cause the QuorumCnxManager.Listener exit
> ---
>
> Key: ZOOKEEPER-2319
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2319
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Zhaohui Yu
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
>
> Given three nodes, the leader on 2, but some issue with this machine, so I 
> shutdown this machine, and change the host name to another machine.
> Then I start the node in the new machine, but the new node can not join.
> I found the the 1 and 3's Listener thread exit.
> With the code of Listener's run method:
> I think we should catch UnresolvedAddressException to avoid the Listener exit.
> {noformat}
> @Override
> public void run() {
>
> while((!shutdown) && (numRetries < 3)){
> try {
>// bind and accept
> receiveConnection(client);
>   
> } catch (IOException e) {
> 
> }
> }
> //
> }
> {noformat}



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

[jira] [Updated] (ZOOKEEPER-2344) Provide more diagnostics/stack traces on SASL Auth failure

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2344:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Provide more diagnostics/stack traces on SASL Auth failure
> --
>
> Key: ZOOKEEPER-2344
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2344
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: java client, server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Steve Loughran
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
>
> When Kerberos decides it doesn't want to work, the JRE libraries provide some 
> terse and unhelpful error messages.
> The only way to debug the problem is (a) to have complete stack traces and 
> (b) as much related information as possible.
> Zookeeper could do more here. Currently too much of the code loses stack 
> traces; sometimes auth errors aren't reported back to the client (the 
> connection is closed) +others
> Everyone who has tried to diagnose kerberos problems will appreciate 
> improvements here



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

[jira] [Commented] (ZOOKEEPER-2344) Provide more diagnostics/stack traces on SASL Auth failure

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2344:
-

I am moving this out to 3.4.10 for now.

> Provide more diagnostics/stack traces on SASL Auth failure
> --
>
> Key: ZOOKEEPER-2344
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2344
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: java client, server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Steve Loughran
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
>
> When Kerberos decides it doesn't want to work, the JRE libraries provide some 
> terse and unhelpful error messages.
> The only way to debug the problem is (a) to have complete stack traces and 
> (b) as much related information as possible.
> Zookeeper could do more here. Currently too much of the code loses stack 
> traces; sometimes auth errors aren't reported back to the client (the 
> connection is closed) +others
> Everyone who has tried to diagnose kerberos problems will appreciate 
> improvements here



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

[jira] [Updated] (ZOOKEEPER-2358) NettyServerCnxn leaks watches upon close

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2358:

Fix Version/s: (was: 3.4.9)
   3.4.10

> NettyServerCnxn leaks watches upon close
> 
>
> Key: ZOOKEEPER-2358
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2358
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Ian Dimayuga
>Assignee: Ian Dimayuga
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2358-3.4.patch, ZOOKEEPER-2358.patch
>
>
> NettyServerCnxn.close() neglects to call zkServer.removeCnxn the way 
> NIOServerCnxn.close() does. Also, WatchLeakTest does not test watch leaks in 
> Netty.



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

[jira] [Updated] (ZOOKEEPER-2389) read-only observer doesn't load transaction log when transitioning to read-only

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2389:

Fix Version/s: (was: 3.4.9)
   3.4.10

> read-only observer doesn't load transaction log when transitioning to 
> read-only
> ---
>
> Key: ZOOKEEPER-2389
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2389
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.8
>Reporter: Jason Rosenberg
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
>
> I have rediscovered an issue, that was apparently posted a while back (link 
> below).  It seems that if I configure an Observer node to be enabled for 
> read-only mode, with syncEnabled = true, it properly syncs its transaction 
> log with the quorum.  However, if I shut down the quorum participants, and 
> the Observer automatically transitions to read-only mode, it does not load 
> the saved transaction log, and thus rejects any client connection with a zxid 
> > 0.  But If I restart the Observer node, it reloads it's persisted 
> transaction log and serves read-only requests at the latest zxid.  Is this 
> the correct behavior? Things run fine if instead of an observer, I do the 
> same with a read-only participant.  In this case, it transitions without 
> issue to a read-only server, and serves the current transaction log.
> It seems to me this issue renders read-only observers completely useless.  
> What am I missing here?
> I'm seeing this with 3.4.8
> It seems this was discovered and reported a long time ago here:
> http://grokbase.com/t/zookeeper/user/14c16b1d22/issue-with-zxid-during-observer-failover-to-read-only



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

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

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2395:

Fix Version/s: (was: 3.4.9)
   3.4.10

> 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.10
>
>
> 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-1884) zkCli silently ignores commands with missing parameters

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-1884:

Fix Version/s: (was: 3.4.9)
   3.4.10

> zkCli silently ignores commands with missing parameters
> ---
>
> Key: ZOOKEEPER-1884
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1884
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Flavio Junqueira
>Assignee: Raul Gutierrez Segales
>Priority: Minor
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-1884.patch
>
>
> Apparently, we have fixed this in trunk, but not in the 3.4 branch. When we 
> pass only the path to create, the command is not executed because it expects 
> an additional parameter and there is no error message because the create 
> command exists.



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

[jira] [Updated] (ZOOKEEPER-2467) NullPointerException when redo Command is passed negative value

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2467:

Fix Version/s: (was: 3.4.9)
   3.4.10

> NullPointerException when redo Command is passed negative value
> ---
>
> Key: ZOOKEEPER-2467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2467
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.8, 3.5.2
> Environment: Linux , windows
>Reporter: Joshi Shankar
>Assignee: Joshi Shankar
>Priority: Minor
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2467-1.patch, ZOOKEEPER-2467-final.patch, 
> ZOOKEEPER-2467.patch, ZOOKEEPER-2467.patch
>
>
> When negative value of argument is passed to redo command .
> [zk: localhost:2181(CONNECTED) 0] redo -1
> Exception in thread "main" java.lang.NullPointerException
> at java.util.StringTokenizer.(Unknown Source)
> at java.util.StringTokenizer.(Unknown Source)
> at 
> org.apache.zookeeper.ZooKeeperMain$MyCommandOptions.parseCommand(ZooKeeperMain.java:227)
> at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:645)
> at 
> org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:588)
> at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:360)
> at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:323)
> at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:282)



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

[jira] [Updated] (ZOOKEEPER-2044) CancelledKeyException in zookeeper 3.4.5

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2044:

Fix Version/s: (was: 3.4.9)
   3.4.10

> CancelledKeyException in zookeeper 3.4.5
> 
>
> Key: ZOOKEEPER-2044
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2044
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
> Environment: Red Hat Enterprise Linux Server release 6.2
>Reporter: shamjith antholi
>Assignee: Flavio Junqueira
>Priority: Minor
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2044.patch, ZOOKEEPER-2044.patch
>
>
> I am getting cancelled key exception in zookeeper (version 3.4.5). Please see 
> the log below. When this error is thrown, the connected solr shard is going 
> down by giving the error "Failed to index metadata in 
> Solr,StackTrace=SolrError: HTTP status 503.Reason: 
> {"responseHeader":{"status":503,"QTime":204},"error":{"msg":"ClusterState 
> says we are the leader, but locally we don't think so","code":503"  and 
> ultimately the current activity is going down. Could you please give a 
> solution for this ?
> Zookeper log 
> --
> 2014-09-16 02:58:47,799 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@832] - Client 
> attempting to renew session 0x24868e7ca980003 at /172.22.0.5:58587
> 2014-09-16 02:58:47,800 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:Learner@107] - Revalidating 
> client: 0x24868e7ca980003
> 2014-09-16 02:58:47,802 [myid:1] - INFO  
> [QuorumPeer[myid=1]/0:0:0:0:0:0:0:0:2181:ZooKeeperServer@588] - Invalid 
> session 0x24868e7ca980003 for client /172.22.0.5:58587, probably expired
> 2014-09-16 02:58:47,803 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1001] - Closed 
> socket connection for client /172.22.0.5:58587 which had sessionid 
> 0x24868e7ca980003
> 2014-09-16 02:58:47,810 [myid:1] - ERROR 
> [CommitProcessor:1:NIOServerCnxn@180] - Unexpected Exception:
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendBuffer(NIOServerCnxn.java:153)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendResponse(NIOServerCnxn.java:1076)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.process(NIOServerCnxn.java:1113)
> at org.apache.zookeeper.server.DataTree.setWatches(DataTree.java:1327)
> at 
> org.apache.zookeeper.server.ZKDatabase.setWatches(ZKDatabase.java:384)
> at 
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:304)
> at 
> org.apache.zookeeper.server.quorum.CommitProcessor.run(CommitProcessor.java:74)
>  



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

[jira] [Updated] (ZOOKEEPER-2365) JAAS configuration section error is confusing

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2365:

Fix Version/s: (was: 3.4.9)
   3.4.10

> JAAS configuration section error is confusing
> -
>
> Key: ZOOKEEPER-2365
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2365
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.6
> Environment: Ubuntu x86_64 openjdk-7-jre
>Reporter: Dan Fitch
>Assignee: Biju Nair
>Priority: Trivial
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2365-1.patch, ZOOKEEPER-2365.patch
>
>
> I have zookeeper running normally just fine in a 3-server cluster.
> Then I try to configure zookeeper to use Kerberos, following docs in the Solr 
> wiki here: 
> https://cwiki.apache.org/confluence/display/solr/Kerberos+Authentication+Plugin
> I can't even get to the fun Kerberos errors. When I start with 
> {{JVMFLAGS="-Djava.security.auth.login.config=/opt/zookeeper/jaas-server.conf"}}
> and this jaas-server.conf:
> {code}
> Server {
> com.sun.security.auth.module.Krb5LoginModule required
> useKeyTab=true
> keyTab=/keytabs/vdev-solr-01.keytab
> storeKey=true
> doNotPrompt=true
> useTicketCache=false
> debug=true
> principal="HTTP/";
> }
> {code}
> I get this in the log:
> {code}
> 2016-02-10 16:16:51,327 [myid:1] - ERROR [main:ServerCnxnFactory@195] - No 
> JAAS configuration section named 'Server' was foundin 
> '/opt/zookeeper/jaas-server.conf'.
> 2016-02-10 16:16:51,328 [myid:1] - ERROR [main:QuorumPeerMain@89] - 
> Unexpected exception, exiting abnormally
> java.io.IOException: No JAAS configuration section named 'Server' was foundin 
> '/opt/zookeeper/jaas-server.conf'.
> at 
> org.apache.zookeeper.server.ServerCnxnFactory.configureSaslLogin(ServerCnxnFactory.java:196)
> at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.configure(NIOServerCnxnFactory.java:87)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:130)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
> {code}
> (Note the "foundin" typo.)
> I get the exact same error if the jaas-server.conf file exists, or does not.
> So later I found that the Solr wiki was wrong and lost the double quotes 
> around the keytab value. It would be nice if Zookeeper spewed a more useful 
> message when it can't parse the configuration.



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

[jira] [Updated] (ZOOKEEPER-2470) ServerConfig#parse(String[]) ignores tickTime

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2470:

Fix Version/s: (was: 3.4.9)
   3.4.10

> ServerConfig#parse(String[])  ignores tickTime
> --
>
> Key: ZOOKEEPER-2470
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2470
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
>Priority: Trivial
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2470.patch
>
>
> Based on bug report from ykgarfield:
> ServerConfig#parse(String[]) method has the following code:
> public void parse(String[] args) {
> ...
> if (args.length == 3) {
> tickTime = Integer.parseInt(args[2]);
> }
> if (args.length == 4) {
> maxClientCnxns = Integer.parseInt(args[3]);
> }
> }
> ```
> So if args.length == 4 tickTime isn't parsed.



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

[jira] [Updated] (ZOOKEEPER-2314) Improvements to SASL

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2314:

Fix Version/s: (was: 3.4.9)
   3.4.10

> Improvements to SASL
> 
>
> Key: ZOOKEEPER-2314
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2314
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
>
> Points that occur to me right now:
> # The login object in ZooKeeperSaslClient is static, which means that if you 
> try to create another client for tests, the login object will be the first 
> one you've set for all runs. I've experienced this with 3.4.6.
> # There are a number of properties spread across the code that do not appear 
> in the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



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

ZOOKEEPER pre-commit fails if patch contains binary file

[Mohammad arshad]

Hello everyone

In ZooKeeper pre-commit patch apply has failed for the patch 
ZOOKEEPER-1260-01.patch. This patch applies on trunk locally
ZOOKEEPER-1260-01.patch contains a binary file. This patch is generated with 
"git diff --no-prefix --binary HEAD > ZOOKEEPER-1260-01.patch" command
I think the binary file, in the patch, is the reason for failure in CI.
any idea on how to give patch in zookeeper which has binary file?

Thanks
-Arshad

ZooKeeper-trunk-solaris - Build # 1272 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-solaris/1272/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 424335 lines...]
[junit] 2016-08-16 08:28:54,909 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-08-16 08:28:54,909 [myid:] - INFO  
[main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2016-08-16 08:28:54,910 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-08-16 08:28:54,911 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-08-16 08:28:54,911 [myid:] - INFO  [main:ZooKeeperServer@889] 
- minSessionTimeout set to 6000
[junit] 2016-08-16 08:28:54,911 [myid:] - INFO  [main:ZooKeeperServer@898] 
- maxSessionTimeout set to 6
[junit] 2016-08-16 08:28:54,911 [myid:] - INFO  [main:ZooKeeperServer@159] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4770438897610769480.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4770438897610769480.junit.dir/version-2
[junit] 2016-08-16 08:28:54,912 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4770438897610769480.junit.dir/version-2/snapshot.b
[junit] 2016-08-16 08:28:54,914 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4770438897610769480.junit.dir/version-2/snapshot.b
[junit] 2016-08-16 08:28:54,915 [myid:] - ERROR [main:ZooKeeperServer@501] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-08-16 08:28:54,916 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-08-16 08:28:54,916 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:62828
[junit] 2016-08-16 08:28:54,917 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:62828
[junit] 2016-08-16 08:28:54,917 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-08-16 08:28:54,917 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:62828 (no session established for client)
[junit] 2016-08-16 08:28:54,918 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-08-16 08:28:54,919 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-08-16 08:28:54,919 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-08-16 08:28:54,919 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-08-16 08:28:54,919 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-08-16 08:28:54,920 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17781
[junit] 2016-08-16 08:28:54,920 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-08-16 08:28:54,920 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-08-16 08:28:54,920 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-08-16 08:28:54,999 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1230f7384ed closed
[junit] 2016-08-16 08:28:54,999 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1230f7384ed
[junit] 2016-08-16 08:28:54,999 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-08-16 08:28:54,999 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-08-16 08:28:54,999 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-08-16 08:28:54,999 [myid:] - INFO  

[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad commented on ZOOKEEPER-1467:


Hi [~gbraccialli],
server principal can have three parts {{serviceName/hostName@realm}}
serviceName can be configured with {{zookeeper.sasl.client.username}}
realm can be configured with {{zookeeper.server.realm}}
only hostName is not configurable. It is taken same as the server IP.
zookeeper.server.principal is being introduced to give the complete principal 
like  {{-Dzookeeper.server.principal=zookeeper/hadoop.hadoop@hadoop.com}}
where hadoop.hadoop.com is the hostName

> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
>Reporter: Laxman
>Assignee: Eugene Koontz
>Priority: Critical
>  Labels: Security, client, kerberos, sasl
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new 
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like 
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.



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