[jira] [Commented] (ZOOKEEPER-2156) If JAVA_HOME is not set zk startup and fetching status command execution result misleads user.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484718#comment-14484718
]
Hadoop QA commented on ZOOKEEPER-2156:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12723821/ZOOKEEPER-2156.3.patch
against trunk revision 1671889.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3)
warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604//console
This message is automatically generated.
> If JAVA_HOME is not set zk startup and fetching status command execution
> result misleads user.
> --
>
> Key: ZOOKEEPER-2156
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2156
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2156.1.patch, ZOOKEEPER-2156.2.patch,
> ZOOKEEPER-2156.3.patch
>
>
> If JAVA_HOME is not set, zk startup and fetching status command execution
> result misleads user.
> 1. Eventhough zk startup has failed since JAVA_HOME is not set , on CLI it
> displays that zk STARTED.
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh start
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Starting zookeeper ... STARTED
> {noformat}
> 2. Fetching zk status when JAVA_HOME is not set displays that process not
> running .
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh status
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Error contacting service. It is probably not running.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Failed: ZOOKEEPER-2156 PreCommit Build #2604
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2156 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 362320 lines...] [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2604//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] fed901c8c8f4097f3422c9aeae14526d845bd75e logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1721: exec returned: 1 Total time: 51 minutes 13 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2594 Archived 24 artifacts Archive block size is 32768 Received 10 blocks and 33667203 bytes Compression is 1.0% Took 10 sec Recording test results Description set: ZOOKEEPER-2156 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Updated] (ZOOKEEPER-2156) If JAVA_HOME is not set zk startup and fetching status command execution result misleads user.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Andreina updated ZOOKEEPER-2156:
--
Attachment: ZOOKEEPER-2156.3.patch
Thanks [~rgs] for reviewing and correcting me.
Have updated the patch as per your suggestion .
Please review.
> If JAVA_HOME is not set zk startup and fetching status command execution
> result misleads user.
> --
>
> Key: ZOOKEEPER-2156
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2156
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2156.1.patch, ZOOKEEPER-2156.2.patch,
> ZOOKEEPER-2156.3.patch
>
>
> If JAVA_HOME is not set, zk startup and fetching status command execution
> result misleads user.
> 1. Eventhough zk startup has failed since JAVA_HOME is not set , on CLI it
> displays that zk STARTED.
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh start
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Starting zookeeper ... STARTED
> {noformat}
> 2. Fetching zk status when JAVA_HOME is not set displays that process not
> running .
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh status
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Error contacting service. It is probably not running.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2157) Upgrade option should be removed from zkServer.sh usage
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484662#comment-14484662
]
J.Andreina commented on ZOOKEEPER-2157:
---
Thanks [~hdeng] for committing the patch.
Thanks [~michim] and [~rakeshr] for adding me to contributor's list.
> Upgrade option should be removed from zkServer.sh usage
> ---
>
> Key: ZOOKEEPER-2157
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2157
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
>Priority: Minor
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2157.1.patch, ZOOKEEPER-2157.2.patch
>
>
> Upgrade option should be removed from zkServer.sh usage from trunk code
> Currently upgrade option is available in zkServer.sh usage , while upgrade
> feature is already been removed from trunk.
> {noformat}
> #:~/March_1/zookeeper/bin> ./zkServer.sh upgrade
> ZooKeeper JMX enabled by default
> Using config: /home/REX/March_1/zookeeper/bin/../conf/zoo.cfg
> Usage: ./zkServer.sh [--config ]
> {start|start-foreground|stop|restart|status|upgrade|print-cmd}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1920) Login thread is not shutdown when close the ClientCnxn
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484609#comment-14484609 ] BOB commented on ZOOKEEPER-1920: hi,liuyang, i want to know what is the status of this patch, now? > Login thread is not shutdown when close the ClientCnxn > -- > > Key: ZOOKEEPER-1920 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1920 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.4.6 >Reporter: liuyang >Priority: Minor > > A new ZooKeeper client will start three threads, the SendThread, EventThread > and LoginThread. I belive that these threads will be shutdown after call the > zk.close. I test that the SendThread and EventThread will be die, but > LoginThread is still alive. The stack is: > "Thread-0" daemon prio=10 tid=0x7ffcf002 nid=0x69c8 waiting on > condition [0x7ffd3cc25000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at org.apache.zookeeper.Login$1.run(Login.java:183) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Pluggable SASL Authentication in Zookeeper
Good point regarding test dependency. Let me try. Yuliya From: Patrick Hunt To: DevZooKeeper ; yuliya Feldman Sent: Tuesday, April 7, 2015 6:51 PM Subject: Re: Pluggable SASL Authentication in Zookeeper Other projects are using minikdc afaik. Solr, oozie, hive, accumulo, hbase, etc... It would be a test dependency. Patrick On Tue, Apr 7, 2015 at 5:43 PM, yuliya Feldman wrote: > I have uploaded updated spec with additional sections regarding backward > compatibility and testing. > Regarding minikdc - this is hadoop subproject. I doubt you want zookeeper > depending on it. On theother hand I am pretty sure minikdc project does not > need to be part of hadoop project since it does not really depend (or does > not need to depend) on anything from hadoop. > Thanks,Yuliya > From: Patrick Hunt > To: DevZooKeeper ; yuliya Feldman < > yufeld...@yahoo.com> > Sent: Tuesday, April 7, 2015 5:16 PM > Subject: Re: Pluggable SASL Authentication in Zookeeper > > That's good to hear (updates and testing with kerb). The minikdc will allow > us to validate as part of the unit tests, which will be a great addition > for folks trying to make changes and ensuring they don't break things. It's > always been a worry of mine with the current setup. > > Patrick > > > > On Tue, Apr 7, 2015 at 5:07 PM, yuliya Feldman > > wrote: > > > Thank you Patrick for replying. > > Certainly everything that is working today should/will work out of the > box > > with pluggable way.Will update a document with test and backward > > compatibility goals. > > I do actually have a patch and UnitTests, though I tested Kerberos with > > real KDC, but all the Unit tests related to SASL were passing OK. > > Thanks,Yuliya > > > > From: Patrick Hunt > > To: DevZooKeeper ; yuliya Feldman < > > yufeld...@yahoo.com> > > Sent: Tuesday, April 7, 2015 4:58 PM > > Subject: Re: Pluggable SASL Authentication in Zookeeper > > > > Sounds like a reasonable goal. I don't see anything about testing, not > > breaking backward compatibility, etc... - I would think that we should > > ensure that kerberos continues to work. When the original sasl work was > > done the minikdc didn't exist, now that it does I think we should pull > that > > in as part of the validation (ensure things don't break). > > > > Patrick > > > > > > > > On Tue, Apr 7, 2015 at 3:15 PM, yuliya Feldman > > > > > wrote: > > > > > Hello here, > > > I was wondering is whether Zookeeper community would benefit from > > > Pluggable SASL Authentication. > > > Today SASLAuthenticationProvider is used for all SASL based > > > authentications which creates some "if/else" statements in > > > ZookeeperSaslClient and ZookeeperSaslServer code even with just > Kerberos > > > and Digest.We want to use yet another different SASL based > authentication > > > and adding one more "if/else" with some code specific just to that new > > way > > > does not make much sense.Proposal is to allow to plug custom SASL > > > Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] > > > Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would > > > appreciate feedback from the community.Thanks,Yuliya > > > > > > > > > > > > > > > > > >
[jira] [Commented] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484541#comment-14484541 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- Yes - you are right on the first part. It may imply that weaker one can be used while original intent was to use stronger one. I listed "negotiation" as an improvement on top of the proposal, since it will require more substantial changes in handling sasl request/response between server and client. > Pluggable SASL Authentication > - > > Key: ZOOKEEPER-2159 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159 > Project: ZooKeeper > Issue Type: Improvement > Components: java client, server >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: PluggableZookeeperAuthentication (1).pdf, > PluggableZookeeperAuthentication.pdf > > > Today SASLAuthenticationProvider is used for all SASL based authentications > which creates some "if/else" statements in ZookeeperSaslClient and > ZookeeperSaslServer code with just Kerberos and Digest. > We want to use yet another different SASL based authentication and adding one > more "if/else" with some code specific just to that new way does not make > much sense. > Proposal is to allow to plug custom SASL Authentication mechanism(s) without > further changes in Zookeeper code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Pluggable SASL Authentication in Zookeeper
Other projects are using minikdc afaik. Solr, oozie, hive, accumulo, hbase, etc... It would be a test dependency. Patrick On Tue, Apr 7, 2015 at 5:43 PM, yuliya Feldman wrote: > I have uploaded updated spec with additional sections regarding backward > compatibility and testing. > Regarding minikdc - this is hadoop subproject. I doubt you want zookeeper > depending on it. On theother hand I am pretty sure minikdc project does not > need to be part of hadoop project since it does not really depend (or does > not need to depend) on anything from hadoop. > Thanks,Yuliya > From: Patrick Hunt > To: DevZooKeeper ; yuliya Feldman < > yufeld...@yahoo.com> > Sent: Tuesday, April 7, 2015 5:16 PM > Subject: Re: Pluggable SASL Authentication in Zookeeper > > That's good to hear (updates and testing with kerb). The minikdc will allow > us to validate as part of the unit tests, which will be a great addition > for folks trying to make changes and ensuring they don't break things. It's > always been a worry of mine with the current setup. > > Patrick > > > > On Tue, Apr 7, 2015 at 5:07 PM, yuliya Feldman > > wrote: > > > Thank you Patrick for replying. > > Certainly everything that is working today should/will work out of the > box > > with pluggable way.Will update a document with test and backward > > compatibility goals. > > I do actually have a patch and UnitTests, though I tested Kerberos with > > real KDC, but all the Unit tests related to SASL were passing OK. > > Thanks,Yuliya > > > > From: Patrick Hunt > > To: DevZooKeeper ; yuliya Feldman < > > yufeld...@yahoo.com> > > Sent: Tuesday, April 7, 2015 4:58 PM > > Subject: Re: Pluggable SASL Authentication in Zookeeper > > > > Sounds like a reasonable goal. I don't see anything about testing, not > > breaking backward compatibility, etc... - I would think that we should > > ensure that kerberos continues to work. When the original sasl work was > > done the minikdc didn't exist, now that it does I think we should pull > that > > in as part of the validation (ensure things don't break). > > > > Patrick > > > > > > > > On Tue, Apr 7, 2015 at 3:15 PM, yuliya Feldman > > > > > wrote: > > > > > Hello here, > > > I was wondering is whether Zookeeper community would benefit from > > > Pluggable SASL Authentication. > > > Today SASLAuthenticationProvider is used for all SASL based > > > authentications which creates some "if/else" statements in > > > ZookeeperSaslClient and ZookeeperSaslServer code even with just > Kerberos > > > and Digest.We want to use yet another different SASL based > authentication > > > and adding one more "if/else" with some code specific just to that new > > way > > > does not make much sense.Proposal is to allow to plug custom SASL > > > Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] > > > Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would > > > appreciate feedback from the community.Thanks,Yuliya > > > > > > > > > > > > > > > > > >
[jira] [Commented] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484531#comment-14484531 ] Eugene Koontz commented on ZOOKEEPER-2159: -- Good document. I like the idea of negotiation of authentication method. However, one thing to keep in mind that currently, there is only a single Access Control Qualifier "sasl". That is, for the purposes of authorization, all "sasl"s are equivalent, so if a user can login with a weak authentication method, they can do anything they could if they had authenticated with a stronger one. Then there is no point in having stronger methods configured, since users are able to authenticate with the weakest. This consideration might imply that we should have configuration options to make SASL authorization more fine-grained, so that instead of a node having an ACL like: sasl:hbase:/hbase:cwrda (read as: :::) it would have something like: sasl:hbase:/hbase:cwrda or: sasl:hbase:/hbase:cwrda > Pluggable SASL Authentication > - > > Key: ZOOKEEPER-2159 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159 > Project: ZooKeeper > Issue Type: Improvement > Components: java client, server >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: PluggableZookeeperAuthentication (1).pdf, > PluggableZookeeperAuthentication.pdf > > > Today SASLAuthenticationProvider is used for all SASL based authentications > which creates some "if/else" statements in ZookeeperSaslClient and > ZookeeperSaslServer code with just Kerberos and Digest. > We want to use yet another different SASL based authentication and adding one > more "if/else" with some code specific just to that new way does not make > much sense. > Proposal is to allow to plug custom SASL Authentication mechanism(s) without > further changes in Zookeeper code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Pluggable SASL Authentication in Zookeeper
I have uploaded updated spec with additional sections regarding backward compatibility and testing. Regarding minikdc - this is hadoop subproject. I doubt you want zookeeper depending on it. On theother hand I am pretty sure minikdc project does not need to be part of hadoop project since it does not really depend (or does not need to depend) on anything from hadoop. Thanks,Yuliya From: Patrick Hunt To: DevZooKeeper ; yuliya Feldman Sent: Tuesday, April 7, 2015 5:16 PM Subject: Re: Pluggable SASL Authentication in Zookeeper That's good to hear (updates and testing with kerb). The minikdc will allow us to validate as part of the unit tests, which will be a great addition for folks trying to make changes and ensuring they don't break things. It's always been a worry of mine with the current setup. Patrick On Tue, Apr 7, 2015 at 5:07 PM, yuliya Feldman wrote: > Thank you Patrick for replying. > Certainly everything that is working today should/will work out of the box > with pluggable way.Will update a document with test and backward > compatibility goals. > I do actually have a patch and UnitTests, though I tested Kerberos with > real KDC, but all the Unit tests related to SASL were passing OK. > Thanks,Yuliya > > From: Patrick Hunt > To: DevZooKeeper ; yuliya Feldman < > yufeld...@yahoo.com> > Sent: Tuesday, April 7, 2015 4:58 PM > Subject: Re: Pluggable SASL Authentication in Zookeeper > > Sounds like a reasonable goal. I don't see anything about testing, not > breaking backward compatibility, etc... - I would think that we should > ensure that kerberos continues to work. When the original sasl work was > done the minikdc didn't exist, now that it does I think we should pull that > in as part of the validation (ensure things don't break). > > Patrick > > > > On Tue, Apr 7, 2015 at 3:15 PM, yuliya Feldman > > wrote: > > > Hello here, > > I was wondering is whether Zookeeper community would benefit from > > Pluggable SASL Authentication. > > Today SASLAuthenticationProvider is used for all SASL based > > authentications which creates some "if/else" statements in > > ZookeeperSaslClient and ZookeeperSaslServer code even with just Kerberos > > and Digest.We want to use yet another different SASL based authentication > > and adding one more "if/else" with some code specific just to that new > way > > does not make much sense.Proposal is to allow to plug custom SASL > > Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] > > Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would > > appreciate feedback from the community.Thanks,Yuliya > > > > > > > >
[jira] [Updated] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2159: -- Attachment: PluggableZookeeperAuthentication (1).pdf Updated Design Doc with Backward Compatibility, Testing section > Pluggable SASL Authentication > - > > Key: ZOOKEEPER-2159 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159 > Project: ZooKeeper > Issue Type: Improvement > Components: java client, server >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: PluggableZookeeperAuthentication (1).pdf, > PluggableZookeeperAuthentication.pdf > > > Today SASLAuthenticationProvider is used for all SASL based authentications > which creates some "if/else" statements in ZookeeperSaslClient and > ZookeeperSaslServer code with just Kerberos and Digest. > We want to use yet another different SASL based authentication and adding one > more "if/else" with some code specific just to that new way does not make > much sense. > Proposal is to allow to plug custom SASL Authentication mechanism(s) without > further changes in Zookeeper code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Pluggable SASL Authentication in Zookeeper
That's good to hear (updates and testing with kerb). The minikdc will allow us to validate as part of the unit tests, which will be a great addition for folks trying to make changes and ensuring they don't break things. It's always been a worry of mine with the current setup. Patrick On Tue, Apr 7, 2015 at 5:07 PM, yuliya Feldman wrote: > Thank you Patrick for replying. > Certainly everything that is working today should/will work out of the box > with pluggable way.Will update a document with test and backward > compatibility goals. > I do actually have a patch and UnitTests, though I tested Kerberos with > real KDC, but all the Unit tests related to SASL were passing OK. > Thanks,Yuliya > > From: Patrick Hunt > To: DevZooKeeper ; yuliya Feldman < > yufeld...@yahoo.com> > Sent: Tuesday, April 7, 2015 4:58 PM > Subject: Re: Pluggable SASL Authentication in Zookeeper > > Sounds like a reasonable goal. I don't see anything about testing, not > breaking backward compatibility, etc... - I would think that we should > ensure that kerberos continues to work. When the original sasl work was > done the minikdc didn't exist, now that it does I think we should pull that > in as part of the validation (ensure things don't break). > > Patrick > > > > On Tue, Apr 7, 2015 at 3:15 PM, yuliya Feldman > > wrote: > > > Hello here, > > I was wondering is whether Zookeeper community would benefit from > > Pluggable SASL Authentication. > > Today SASLAuthenticationProvider is used for all SASL based > > authentications which creates some "if/else" statements in > > ZookeeperSaslClient and ZookeeperSaslServer code even with just Kerberos > > and Digest.We want to use yet another different SASL based authentication > > and adding one more "if/else" with some code specific just to that new > way > > does not make much sense.Proposal is to allow to plug custom SASL > > Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] > > Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would > > appreciate feedback from the community.Thanks,Yuliya > > > > > > > >
Re: Pluggable SASL Authentication in Zookeeper
Thank you Patrick for replying. Certainly everything that is working today should/will work out of the box with pluggable way.Will update a document with test and backward compatibility goals. I do actually have a patch and UnitTests, though I tested Kerberos with real KDC, but all the Unit tests related to SASL were passing OK. Thanks,Yuliya From: Patrick Hunt To: DevZooKeeper ; yuliya Feldman Sent: Tuesday, April 7, 2015 4:58 PM Subject: Re: Pluggable SASL Authentication in Zookeeper Sounds like a reasonable goal. I don't see anything about testing, not breaking backward compatibility, etc... - I would think that we should ensure that kerberos continues to work. When the original sasl work was done the minikdc didn't exist, now that it does I think we should pull that in as part of the validation (ensure things don't break). Patrick On Tue, Apr 7, 2015 at 3:15 PM, yuliya Feldman wrote: > Hello here, > I was wondering is whether Zookeeper community would benefit from > Pluggable SASL Authentication. > Today SASLAuthenticationProvider is used for all SASL based > authentications which creates some "if/else" statements in > ZookeeperSaslClient and ZookeeperSaslServer code even with just Kerberos > and Digest.We want to use yet another different SASL based authentication > and adding one more "if/else" with some code specific just to that new way > does not make much sense.Proposal is to allow to plug custom SASL > Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] > Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would > appreciate feedback from the community.Thanks,Yuliya > >
Re: Pluggable SASL Authentication in Zookeeper
Sounds like a reasonable goal. I don't see anything about testing, not breaking backward compatibility, etc... - I would think that we should ensure that kerberos continues to work. When the original sasl work was done the minikdc didn't exist, now that it does I think we should pull that in as part of the validation (ensure things don't break). Patrick On Tue, Apr 7, 2015 at 3:15 PM, yuliya Feldman wrote: > Hello here, > I was wondering is whether Zookeeper community would benefit from > Pluggable SASL Authentication. > Today SASLAuthenticationProvider is used for all SASL based > authentications which creates some "if/else" statements in > ZookeeperSaslClient and ZookeeperSaslServer code even with just Kerberos > and Digest.We want to use yet another different SASL based authentication > and adding one more "if/else" with some code specific just to that new way > does not make much sense.Proposal is to allow to plug custom SASL > Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] > Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would > appreciate feedback from the community.Thanks,Yuliya > >
Pluggable SASL Authentication in Zookeeper
Hello here, I was wondering is whether Zookeeper community would benefit from Pluggable SASL Authentication. Today SASLAuthenticationProvider is used for all SASL based authentications which creates some "if/else" statements in ZookeeperSaslClient and ZookeeperSaslServer code even with just Kerberos and Digest.We want to use yet another different SASL based authentication and adding one more "if/else" with some code specific just to that new way does not make much sense.Proposal is to allow to plug custom SASL Authentication mechanism(s).I have submitted JIRA: [ZOOKEEPER-2159] Pluggable SASL Authentication - ASF JIRAwith the proposal, so I would appreciate feedback from the community.Thanks,Yuliya
[jira] [Commented] (ZOOKEEPER-1784) Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484061#comment-14484061
]
Alexander Shraer commented on ZOOKEEPER-1784:
-
done. thanks for noticing this.
> Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
>
>
> Key: ZOOKEEPER-1784
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1784
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
> Fix For: 3.5.1
>
> Attachments: ZOOKEEPER-1784.patch, ZOOKEEPER-1784.patch
>
>
> If you look at Learner#syncWithLeader:
> {noformat}
> while (self.isRunning()) {
> readPacket(qp);
> switch(qp.getType()) {
> ...
> case Leader.INFORM:
> case Leader.INFORMANDACTIVATE:
> PacketInFlight packet = new PacketInFlight();
> packet.hdr = new TxnHeader();
> if (qp.getType() == Leader.COMMITANDACTIVATE) {
> {noformat}
> I guess "qp.getType() == Leader.COMMITANDACTIVATE" is a typo that should read
> "qp.getType() == Leader.INFORMANDACTIVATE".
> Assigning to Alexander for now since this is part of ZOOKEEPER-107.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2156) If JAVA_HOME is not set zk startup and fetching status command execution result misleads user.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483872#comment-14483872
]
Raul Gutierrez Segales commented on ZOOKEEPER-2156:
---
Hi [~andreina],
If JAVA_HOME isn't set, we default to whatever is available in $Path. See:
https://github.com/apache/zookeeper/commit/90ef80c0a2593207be5436acf0270c1e160f0c78
Maybe your patch should only error out if JAVA_HOME isn't set *and* there's no
java in the $PATH?
> If JAVA_HOME is not set zk startup and fetching status command execution
> result misleads user.
> --
>
> Key: ZOOKEEPER-2156
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2156
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2156.1.patch, ZOOKEEPER-2156.2.patch
>
>
> If JAVA_HOME is not set, zk startup and fetching status command execution
> result misleads user.
> 1. Eventhough zk startup has failed since JAVA_HOME is not set , on CLI it
> displays that zk STARTED.
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh start
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Starting zookeeper ... STARTED
> {noformat}
> 2. Fetching zk status when JAVA_HOME is not set displays that process not
> running .
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh status
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Error contacting service. It is probably not running.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1784) Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483607#comment-14483607
]
Raul Gutierrez Segales commented on ZOOKEEPER-1784:
---
Should go to branch-3.5 as well.
> Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
>
>
> Key: ZOOKEEPER-1784
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1784
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
> Fix For: 3.5.1
>
> Attachments: ZOOKEEPER-1784.patch, ZOOKEEPER-1784.patch
>
>
> If you look at Learner#syncWithLeader:
> {noformat}
> while (self.isRunning()) {
> readPacket(qp);
> switch(qp.getType()) {
> ...
> case Leader.INFORM:
> case Leader.INFORMANDACTIVATE:
> PacketInFlight packet = new PacketInFlight();
> packet.hdr = new TxnHeader();
> if (qp.getType() == Leader.COMMITANDACTIVATE) {
> {noformat}
> I guess "qp.getType() == Leader.COMMITANDACTIVATE" is a typo that should read
> "qp.getType() == Leader.INFORMANDACTIVATE".
> Assigning to Alexander for now since this is part of ZOOKEEPER-107.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1784) Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483599#comment-14483599
]
Hongchao Deng commented on ZOOKEEPER-1784:
--
BTW, the fix-versions says "3.5.1".
I think it should also go into branch-3.5
> Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
>
>
> Key: ZOOKEEPER-1784
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1784
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
> Fix For: 3.5.1
>
> Attachments: ZOOKEEPER-1784.patch, ZOOKEEPER-1784.patch
>
>
> If you look at Learner#syncWithLeader:
> {noformat}
> while (self.isRunning()) {
> readPacket(qp);
> switch(qp.getType()) {
> ...
> case Leader.INFORM:
> case Leader.INFORMANDACTIVATE:
> PacketInFlight packet = new PacketInFlight();
> packet.hdr = new TxnHeader();
> if (qp.getType() == Leader.COMMITANDACTIVATE) {
> {noformat}
> I guess "qp.getType() == Leader.COMMITANDACTIVATE" is a typo that should read
> "qp.getType() == Leader.INFORMANDACTIVATE".
> Assigning to Alexander for now since this is part of ZOOKEEPER-107.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1784) Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483597#comment-14483597
]
Hongchao Deng commented on ZOOKEEPER-1784:
--
[~shralex]
I realize this patch is missing in branch-3.5.
Is it on purpose?
> Logic to process INFORMANDACTIVATE packets in syncWithLeader seems bogus
>
>
> Key: ZOOKEEPER-1784
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1784
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
> Fix For: 3.5.1
>
> Attachments: ZOOKEEPER-1784.patch, ZOOKEEPER-1784.patch
>
>
> If you look at Learner#syncWithLeader:
> {noformat}
> while (self.isRunning()) {
> readPacket(qp);
> switch(qp.getType()) {
> ...
> case Leader.INFORM:
> case Leader.INFORMANDACTIVATE:
> PacketInFlight packet = new PacketInFlight();
> packet.hdr = new TxnHeader();
> if (qp.getType() == Leader.COMMITANDACTIVATE) {
> {noformat}
> I guess "qp.getType() == Leader.COMMITANDACTIVATE" is a typo that should read
> "qp.getType() == Leader.INFORMANDACTIVATE".
> Assigning to Alexander for now since this is part of ZOOKEEPER-107.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2157) Upgrade option should be removed from zkServer.sh usage
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483570#comment-14483570
]
Hongchao Deng commented on ZOOKEEPER-2157:
--
Committed!
trunk
svn: http://svn.apache.org/viewvc?view=revision&revision=1671891
git:
https://github.com/apache/zookeeper/commit/f5fb50ed2591ba9a24685a227bb5374759516828
branch-3.5:
svn: http://svn.apache.org/viewvc?view=revision&revision=1671891
git:
https://github.com/apache/zookeeper/commit/ed2f766dd1856df65f85d69094264343939a52d2
> Upgrade option should be removed from zkServer.sh usage
> ---
>
> Key: ZOOKEEPER-2157
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2157
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
>Priority: Minor
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2157.1.patch, ZOOKEEPER-2157.2.patch
>
>
> Upgrade option should be removed from zkServer.sh usage from trunk code
> Currently upgrade option is available in zkServer.sh usage , while upgrade
> feature is already been removed from trunk.
> {noformat}
> #:~/March_1/zookeeper/bin> ./zkServer.sh upgrade
> ZooKeeper JMX enabled by default
> Using config: /home/REX/March_1/zookeeper/bin/../conf/zoo.cfg
> Usage: ./zkServer.sh [--config ]
> {start|start-foreground|stop|restart|status|upgrade|print-cmd}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
ZooKeeper-trunk-jdk8 - Build # 345 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk-jdk8/345/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 359367 lines...] [junit] 2015-04-07 13:41:17,997 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 13:41:17,997 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2015-04-07 13:41:17,999 [myid:] - INFO [main:ClientBase@461] - STARTING server [junit] 2015-04-07 13:41:17,999 [myid:] - INFO [main:ClientBase@381] - CREATING server instance 127.0.0.1:11221 [junit] 2015-04-07 13:41:17,999 [myid:] - INFO [main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s sessionless connection timeout, 2 selector thread(s), 32 worker threads, and 64 kB direct buffers. [junit] 2015-04-07 13:41:18,000 [myid:] - INFO [main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2015-04-07 13:41:18,000 [myid:] - INFO [main:ClientBase@356] - STARTING server instance 127.0.0.1:11221 [junit] 2015-04-07 13:41:18,001 [myid:] - INFO [main:ZooKeeperServer@825] - minSessionTimeout set to 6000 [junit] 2015-04-07 13:41:18,001 [myid:] - INFO [main:ZooKeeperServer@834] - maxSessionTimeout set to 6 [junit] 2015-04-07 13:41:18,001 [myid:] - INFO [main:ZooKeeperServer@156] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test3735750992779795893.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test3735750992779795893.junit.dir/version-2 [junit] 2015-04-07 13:41:18,002 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test3735750992779795893.junit.dir/version-2/snapshot.b [junit] 2015-04-07 13:41:18,004 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test3735750992779795893.junit.dir/version-2/snapshot.b [junit] 2015-04-07 13:41:18,007 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 13:41:18,008 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:41502 [junit] 2015-04-07 13:41:18,008 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@836] - Processing stat command from /127.0.0.1:41502 [junit] 2015-04-07 13:41:18,009 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@685] - Stat command output [junit] 2015-04-07 13:41:18,009 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:41502 (no session established for client) [junit] 2015-04-07 13:41:18,009 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2015-04-07 13:41:18,011 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2015-04-07 13:41:18,011 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2015-04-07 13:41:18,012 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2015-04-07 13:41:18,012 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-07 13:41:18,012 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 62027 [junit] 2015-04-07 13:41:18,012 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2015-04-07 13:41:18,013 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2015-04-07 13:41:18,013 [myid:] - INFO [main:ClientBase@538] - tearDown starting [junit] 2015-04-07 13:41:18,072 [myid:] - INFO [main:ZooKeeper@] - Session: 0x103bc734695 closed [junit] 2015-04-07 13:41:18,072 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@531] - EventThread shut down [junit] 2015-04-07 13:41:18,073 [myid:] - INFO [main:ClientBase@508] - STOPPING server [junit] 2015-04-07 13:41:18,073 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2015-04-07 13:41:18,073 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2015-04-07 13:41:18,073 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thre
[jira] [Resolved] (ZOOKEEPER-2160) just test
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhu resolved ZOOKEEPER-2160. Resolution: Invalid > just test > - > > Key: ZOOKEEPER-2160 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2160 > Project: ZooKeeper > Issue Type: Wish >Reporter: zhu >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2160) just test
zhu created ZOOKEEPER-2160: -- Summary: just test Key: ZOOKEEPER-2160 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2160 Project: ZooKeeper Issue Type: Wish Reporter: zhu Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.4#6332)
ZooKeeper-trunk - Build # 2653 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk/2653/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 361926 lines...] [junit] 2015-04-07 11:14:59,184 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 11:14:59,185 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:52922 [junit] 2015-04-07 11:14:59,186 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@836] - Processing stat command from /127.0.0.1:52922 [junit] 2015-04-07 11:14:59,186 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@685] - Stat command output [junit] 2015-04-07 11:14:59,186 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:52922 (no session established for client) [junit] 2015-04-07 11:14:59,187 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2015-04-07 11:14:59,189 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2015-04-07 11:14:59,189 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2015-04-07 11:14:59,189 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2015-04-07 11:14:59,189 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-07 11:14:59,190 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 85069 [junit] 2015-04-07 11:14:59,190 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2015-04-07 11:14:59,190 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2015-04-07 11:14:59,190 [myid:] - INFO [main:ClientBase@538] - tearDown starting [junit] 2015-04-07 11:14:59,249 [myid:] - INFO [main:ZooKeeper@] - Session: 0x101238b53dc closed [junit] 2015-04-07 11:14:59,250 [myid:] - INFO [main:ClientBase@508] - STOPPING server [junit] 2015-04-07 11:14:59,250 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@531] - EventThread shut down [junit] 2015-04-07 11:14:59,250 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2015-04-07 11:14:59,250 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2015-04-07 11:14:59,250 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2015-04-07 11:14:59,251 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2015-04-07 11:14:59,251 [myid:] - INFO [main:ZooKeeperServer@465] - shutting down [junit] 2015-04-07 11:14:59,251 [myid:] - INFO [main:SessionTrackerImpl@232] - Shutting down [junit] 2015-04-07 11:14:59,251 [myid:] - INFO [main:PrepRequestProcessor@973] - Shutting down [junit] 2015-04-07 11:14:59,251 [myid:] - INFO [main:SyncRequestProcessor@191] - Shutting down [junit] 2015-04-07 11:14:59,252 [myid:] - INFO [ProcessThread(sid:0 cport:11221)::PrepRequestProcessor@155] - PrepRequestProcessor exited loop! [junit] 2015-04-07 11:14:59,252 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited! [junit] 2015-04-07 11:14:59,252 [myid:] - INFO [main:FinalRequestProcessor@489] - shutdown of request processor complete [junit] 2015-04-07 11:14:59,253 [myid:] - INFO [main:MBeanRegistry@119] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree] [junit] 2015-04-07 11:14:59,253 [myid:] - INFO [main:MBeanRegistry@119] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11221] [junit] 2015-04-07 11:14:59,254 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 11:14:59,254 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2015-04-07 11:14:59,258 [myid:] - INFO [main:ClientBase@563] - fdcount after test is: 46 at start it was 34 [junit] 2015-04-07 11:14:59,258 [myid:] - INFO [main:ClientBase@565] - sleeping for 20 secs [junit] 2015-04-07 11:14:59,260 [myid:] - INFO [main:ZKTestCase$1@65] - SUCCEEDED testQuota [junit] 2015-04-07 11:14:59,260 [myid:] - INFO [main:ZKTestCase$1@60] - FINISHED testQuota [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,
[jira] [Commented] (ZOOKEEPER-2056) Zookeeper 3.4.x and 3.5.0-alpha is not OSGi compliant
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483024#comment-14483024 ] Hudson commented on ZOOKEEPER-2056: --- FAILURE: Integrated in ZooKeeper-trunk #2653 (See [https://builds.apache.org/job/ZooKeeper-trunk/2653/]) ZOOKEEPER-2056 Zookeeper 3.4.x and 3.5.0-alpha is not OSGi compliant (Deiwin Sarjas via rgs) (rgs: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1671712) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/build.xml > Zookeeper 3.4.x and 3.5.0-alpha is not OSGi compliant > - > > Key: ZOOKEEPER-2056 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2056 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6, 3.5.0 >Reporter: Keren Dong >Assignee: Deiwin Sarjas > Labels: easyfix > Fix For: 3.4.7, 3.5.1, 3.6.0 > > Attachments: ZOOKEEPER-2056.patch > > > Similar to this issue https://issues.apache.org/jira/browse/ZOOKEEPER-1334, > the MANIFEST.MF is still flawed. When using in OSGi, I got this exception: > java.lang.NoClassDefFoundError: org/ietf/jgss/GSSException > at > org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1063)[168:org.apache.hadoop.zookeeper:3.5.01] > at > org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1114)[168:org.apache.hadoop.zookeeper:3.5.01] > Caused by: java.lang.ClassNotFoundException: org.ietf.jgss.GSSException not > found by org.apache.hadoop.zookeeper [168] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.2.1.jar:] > at > org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.2.1.jar:] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)[org.apache.felix.framework-4.2.1.jar:] > at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_15] > ... 2 more > Looking at the bundle headers, it doesn't have the package org.ietf.jgss > imported: > Import-Package = > javax.management;resolution:=optional, > javax.security.auth.callback, > javax.security.auth.login, > javax.security.sasl, > org.slf4j;version="[1.6,2)", > org.jboss.netty.buffer;resolution:=optional;version="[3.2,4)", > org.jboss.netty.channel;resolution:=optional;version="[3.2,4)", > org.jboss.netty.channel.group;resolution:=optional;version="[3.2,4)", > > org.jboss.netty.channel.socket.nio;resolution:=optional;version="[3.2,4)", > org.osgi.framework;resolution:=optional;version="[1.5,2)", > org.osgi.util.tracker;resolution:=optional;version="[1.4,2)" > Export-Package = > org.apache.zookeeper;version=3.5.01, > org.apache.zookeeper.client;version=3.5.01, > org.apache.zookeeper.data;version=3.5.01, > org.apache.zookeeper.version;version=3.5.01, > org.apache.zookeeper.server;version=3.5.01, > org.apache.zookeeper.server.auth;version=3.5.01, > org.apache.zookeeper.server.persistence;version=3.5.01, > org.apache.zookeeper.server.quorum;version=3.5.01, > org.apache.zookeeper.common;version=3.5.01 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
ZooKeeper_branch34_jdk7 - Build # 849 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch34_jdk7/849/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 212270 lines...] [junit] 2015-04-07 10:29:39,996 [myid:] - INFO [main:JMXEnv@246] - expect:StandaloneServer_port [junit] 2015-04-07 10:29:39,996 [myid:] - INFO [main:JMXEnv@250] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-07 10:29:39,996 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2015-04-07 10:29:39,996 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - NIOServerCnxn factory exited run method [junit] 2015-04-07 10:29:39,996 [myid:] - INFO [main:ZooKeeperServer@441] - shutting down [junit] 2015-04-07 10:29:39,997 [myid:] - INFO [main:SessionTrackerImpl@225] - Shutting down [junit] 2015-04-07 10:29:39,997 [myid:] - INFO [main:PrepRequestProcessor@760] - Shutting down [junit] 2015-04-07 10:29:39,997 [myid:] - INFO [main:SyncRequestProcessor@209] - Shutting down [junit] 2015-04-07 10:29:39,997 [myid:] - INFO [ProcessThread(sid:0 cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop! [junit] 2015-04-07 10:29:39,997 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited! [junit] 2015-04-07 10:29:39,998 [myid:] - INFO [main:FinalRequestProcessor@415] - shutdown of request processor complete [junit] 2015-04-07 10:29:39,998 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 10:29:39,999 [myid:] - INFO [main:JMXEnv@146] - ensureOnly:[] [junit] 2015-04-07 10:29:40,000 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2015-04-07 10:29:40,001 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2015-04-07 10:29:40,001 [myid:] - INFO [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2015-04-07 10:29:40,001 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2015-04-07 10:29:40,002 [myid:] - INFO [main:ZooKeeperServer@162] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test1701405687636855283.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test1701405687636855283.junit.dir/version-2 [junit] 2015-04-07 10:29:40,005 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 10:29:40,006 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:51497 [junit] 2015-04-07 10:29:40,006 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing stat command from /127.0.0.1:51497 [junit] 2015-04-07 10:29:40,007 [myid:] - INFO [Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output [junit] 2015-04-07 10:29:40,007 [myid:] - INFO [Thread-4:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:51497 (no session established for client) [junit] 2015-04-07 10:29:40,007 [myid:] - INFO [main:JMXEnv@229] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2015-04-07 10:29:40,009 [myid:] - INFO [main:JMXEnv@246] - expect:InMemoryDataTree [junit] 2015-04-07 10:29:40,010 [myid:] - INFO [main:JMXEnv@250] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2015-04-07 10:29:40,010 [myid:] - INFO [main:JMXEnv@246] - expect:StandaloneServer_port [junit] 2015-04-07 10:29:40,010 [myid:] - INFO [main:JMXEnv@250] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-07 10:29:40,010 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 10472 [junit] 2015-04-07 10:29:40,011 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 20 [junit] 2015-04-07 10:29:40,011 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2015-04-07 10:29:40,011 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2015-04-07 10:29:40,081 [myid:] - INFO [main:ZooKeeper@684] - Session: 0x14c936da97f closed [junit] 2015-04-07 10:29:40,081 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2015-04-07 10:29:40,081 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@512] - EventThread shut down [junit] 2015-04-07 10:29:40,081 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221
how to do online migration[zookeeper]
Hi, all I have some clusters using different zookeeper cluster(e.g hbase use 'zk1', storm use 'zk2', kafka use 'zk3'.) Now I want to online migrate the three zk cluster to a new zk cluster 'zk4'. In the process of migration, we couldn't stop the services of hbase, storm, kaka... 1. Zookeeper support add/remove a node to/from zk cluster, so I can online migrate a old zk cluster to a new zk cluster, but how to online migrate three old zk cluster to a new zk cluster? 2. After migrating the zk cluster, we have to change the configuration 'hbase.zookeeper.quorum' of hbase, storm, kafka to use the new zk cluster. So could these services support reconfig dynamically? Could anyone help me? -- Thanks, Xiaomeng
[jira] [Updated] (ZOOKEEPER-2156) If JAVA_HOME is not set zk startup and fetching status command execution result misleads user.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michi Mutsuzaki updated ZOOKEEPER-2156:
---
Fix Version/s: 3.6.0
> If JAVA_HOME is not set zk startup and fetching status command execution
> result misleads user.
> --
>
> Key: ZOOKEEPER-2156
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2156
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2156.1.patch, ZOOKEEPER-2156.2.patch
>
>
> If JAVA_HOME is not set, zk startup and fetching status command execution
> result misleads user.
> 1. Eventhough zk startup has failed since JAVA_HOME is not set , on CLI it
> displays that zk STARTED.
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh start
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Starting zookeeper ... STARTED
> {noformat}
> 2. Fetching zk status when JAVA_HOME is not set displays that process not
> running .
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh status
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Error contacting service. It is probably not running.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2156) If JAVA_HOME is not set zk startup and fetching status command execution result misleads user.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Andreina reassigned ZOOKEEPER-2156:
-
Assignee: J.Andreina
> If JAVA_HOME is not set zk startup and fetching status command execution
> result misleads user.
> --
>
> Key: ZOOKEEPER-2156
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2156
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
> Attachments: ZOOKEEPER-2156.1.patch, ZOOKEEPER-2156.2.patch
>
>
> If JAVA_HOME is not set, zk startup and fetching status command execution
> result misleads user.
> 1. Eventhough zk startup has failed since JAVA_HOME is not set , on CLI it
> displays that zk STARTED.
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh start
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Starting zookeeper ... STARTED
> {noformat}
> 2. Fetching zk status when JAVA_HOME is not set displays that process not
> running .
> {noformat}
> #:~/Apr3rd/zookeeper-3.4.6/bin> ./zkServer.sh status
> JMX enabled by default
> Using config: /home/REX/Apr3rd/zookeeper-3.4.6/bin/../conf/zoo.cfg
> Error contacting service. It is probably not running.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
ZooKeeper-trunk-solaris - Build # 993 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/993/
###
## LAST 60 LINES OF THE CONSOLE
###
Started by timer
Building remotely on solaris1 (Solaris) in workspace
/export/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris
Updating http://svn.apache.org/repos/asf/zookeeper/trunk at revision
'2015-04-07T08:32:09.726 +'
U CHANGES.txt
U build.xml
At revision 1671760
Updating http://svn.apache.org/repos/asf/hadoop/nightly at revision
'2015-04-07T08:32:09.726 +'
At revision 1671760
no change for http://svn.apache.org/repos/asf/hadoop/nightly since the previous
build
No emails were triggered.
[locks-and-latches] Checking to see if we really have the locks
[locks-and-latches] Have all the locks, build can start
[ZooKeeper-trunk-solaris] $ /bin/bash /var/tmp/hudson5311412864785593100.sh
[trunk] $
/export/home/hudson/hudson-slave/tools/hudson.tasks.Ant_AntInstallation/ant-1.8.2/bin/ant
"-DBUILD_ARGS=-Dfindbugs.home=${FINDBUGS_HOME} -Dforrest.home=${FORREST_HOME}
-Djava5.home=${JAVA5_HOME}" -DBUILD_TARGETS=hudson-test-trunk
-DANALYSIS_TARGETS=test "-DBUILD_FLAGS=-Dtest.junit.output.format=xml
-Dtest.output=yes " -Dtest.output=yes -Dtest.junit.output.format=xml clean
test-core-java
Error: JAVA_HOME is not defined correctly.
We cannot execute /home/jenkins/tools/java/latest1.7/bin/java
Build step 'Invoke Ant' marked build as failure
[locks-and-latches] Releasing all the locks
[locks-and-latches] All the locks released
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
###
## FAILED TESTS (if any)
##
No tests ran.
[jira] [Updated] (ZOOKEEPER-2157) Upgrade option should be removed from zkServer.sh usage
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michi Mutsuzaki updated ZOOKEEPER-2157:
---
Assignee: J.Andreina
> Upgrade option should be removed from zkServer.sh usage
> ---
>
> Key: ZOOKEEPER-2157
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2157
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: J.Andreina
>Assignee: J.Andreina
>Priority: Minor
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2157.1.patch, ZOOKEEPER-2157.2.patch
>
>
> Upgrade option should be removed from zkServer.sh usage from trunk code
> Currently upgrade option is available in zkServer.sh usage , while upgrade
> feature is already been removed from trunk.
> {noformat}
> #:~/March_1/zookeeper/bin> ./zkServer.sh upgrade
> ZooKeeper JMX enabled by default
> Using config: /home/REX/March_1/zookeeper/bin/../conf/zoo.cfg
> Usage: ./zkServer.sh [--config ]
> {start|start-foreground|stop|restart|status|upgrade|print-cmd}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
ZooKeeper_branch34_solaris - Build # 968 - Failure
See https://builds.apache.org/job/ZooKeeper_branch34_solaris/968/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 164566 lines...] [junit] 2015-04-07 07:56:36,013 [myid:] - INFO [main:JMXEnv@246] - expect:StandaloneServer_port [junit] 2015-04-07 07:56:36,013 [myid:] - INFO [main:JMXEnv@250] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-07 07:56:36,013 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2015-04-07 07:56:36,014 [myid:] - INFO [main:ZooKeeperServer@441] - shutting down [junit] 2015-04-07 07:56:36,014 [myid:] - INFO [main:SessionTrackerImpl@225] - Shutting down [junit] 2015-04-07 07:56:36,014 [myid:] - INFO [main:PrepRequestProcessor@760] - Shutting down [junit] 2015-04-07 07:56:36,015 [myid:] - INFO [main:SyncRequestProcessor@209] - Shutting down [junit] 2015-04-07 07:56:36,015 [myid:] - INFO [ProcessThread(sid:0 cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop! [junit] 2015-04-07 07:56:36,015 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited! [junit] 2015-04-07 07:56:36,015 [myid:] - INFO [main:FinalRequestProcessor@415] - shutdown of request processor complete [junit] 2015-04-07 07:56:36,015 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 07:56:36,016 [myid:] - INFO [main:JMXEnv@146] - ensureOnly:[] [junit] 2015-04-07 07:56:36,017 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2015-04-07 07:56:36,017 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2015-04-07 07:56:36,017 [myid:] - INFO [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2015-04-07 07:56:36,017 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2015-04-07 07:56:36,018 [myid:] - INFO [main:ZooKeeperServer@162] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test9188566272978634233.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test9188566272978634233.junit.dir/version-2 [junit] 2015-04-07 07:56:36,020 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2015-04-07 07:56:36,021 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:56824 [junit] 2015-04-07 07:56:36,021 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing stat command from /127.0.0.1:56824 [junit] 2015-04-07 07:56:36,021 [myid:] - INFO [Thread-5:NIOServerCnxn$StatCommand@663] - Stat command output [junit] 2015-04-07 07:56:36,022 [myid:] - INFO [Thread-5:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:56824 (no session established for client) [junit] 2015-04-07 07:56:36,022 [myid:] - INFO [main:JMXEnv@229] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2015-04-07 07:56:36,023 [myid:] - INFO [main:JMXEnv@246] - expect:InMemoryDataTree [junit] 2015-04-07 07:56:36,023 [myid:] - INFO [main:JMXEnv@250] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2015-04-07 07:56:36,023 [myid:] - INFO [main:JMXEnv@246] - expect:StandaloneServer_port [junit] 2015-04-07 07:56:36,023 [myid:] - INFO [main:JMXEnv@250] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-07 07:56:36,024 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 8882 [junit] 2015-04-07 07:56:36,024 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 19 [junit] 2015-04-07 07:56:36,024 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2015-04-07 07:56:36,024 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2015-04-07 07:56:36,100 [myid:] - INFO [main:ZooKeeper@684] - Session: 0x14c92e184d8 closed [junit] 2015-04-07 07:56:36,100 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@512] - EventThread shut down [junit] 2015-04-07 07:56:36,100 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2015-04-07 07:56:36,101 [myid:] - INFO [main:ZooKeeperServer@441] - shutting down [junit] 2015-04-07 07:56:36,101 [myid:] - INFO [main:SessionTrackerImpl@225] - Shutting down [junit] 2015-04
[jira] [Commented] (ZOOKEEPER-2056) Zookeeper 3.4.x and 3.5.0-alpha is not OSGi compliant
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482743#comment-14482743 ] Deiwin Sarjas commented on ZOOKEEPER-2056: -- Thanks, guys! > Zookeeper 3.4.x and 3.5.0-alpha is not OSGi compliant > - > > Key: ZOOKEEPER-2056 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2056 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6, 3.5.0 >Reporter: Keren Dong >Assignee: Deiwin Sarjas > Labels: easyfix > Fix For: 3.4.7, 3.5.1, 3.6.0 > > Attachments: ZOOKEEPER-2056.patch > > > Similar to this issue https://issues.apache.org/jira/browse/ZOOKEEPER-1334, > the MANIFEST.MF is still flawed. When using in OSGi, I got this exception: > java.lang.NoClassDefFoundError: org/ietf/jgss/GSSException > at > org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1063)[168:org.apache.hadoop.zookeeper:3.5.01] > at > org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1114)[168:org.apache.hadoop.zookeeper:3.5.01] > Caused by: java.lang.ClassNotFoundException: org.ietf.jgss.GSSException not > found by org.apache.hadoop.zookeeper [168] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.2.1.jar:] > at > org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.2.1.jar:] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)[org.apache.felix.framework-4.2.1.jar:] > at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_15] > ... 2 more > Looking at the bundle headers, it doesn't have the package org.ietf.jgss > imported: > Import-Package = > javax.management;resolution:=optional, > javax.security.auth.callback, > javax.security.auth.login, > javax.security.sasl, > org.slf4j;version="[1.6,2)", > org.jboss.netty.buffer;resolution:=optional;version="[3.2,4)", > org.jboss.netty.channel;resolution:=optional;version="[3.2,4)", > org.jboss.netty.channel.group;resolution:=optional;version="[3.2,4)", > > org.jboss.netty.channel.socket.nio;resolution:=optional;version="[3.2,4)", > org.osgi.framework;resolution:=optional;version="[1.5,2)", > org.osgi.util.tracker;resolution:=optional;version="[1.4,2)" > Export-Package = > org.apache.zookeeper;version=3.5.01, > org.apache.zookeeper.client;version=3.5.01, > org.apache.zookeeper.data;version=3.5.01, > org.apache.zookeeper.version;version=3.5.01, > org.apache.zookeeper.server;version=3.5.01, > org.apache.zookeeper.server.auth;version=3.5.01, > org.apache.zookeeper.server.persistence;version=3.5.01, > org.apache.zookeeper.server.quorum;version=3.5.01, > org.apache.zookeeper.common;version=3.5.01 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2159: -- Attachment: PluggableZookeeperAuthentication.pdf This is a Draft of a proposal for Pluggable SASL Authentication in Zookeeper. Would be nice to get initial feedback on this. > Pluggable SASL Authentication > - > > Key: ZOOKEEPER-2159 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159 > Project: ZooKeeper > Issue Type: Improvement > Components: java client, server >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: PluggableZookeeperAuthentication.pdf > > > Today SASLAuthenticationProvider is used for all SASL based authentications > which creates some "if/else" statements in ZookeeperSaslClient and > ZookeeperSaslServer code with just Kerberos and Digest. > We want to use yet another different SASL based authentication and adding one > more "if/else" with some code specific just to that new way does not make > much sense. > Proposal is to allow to plug custom SASL Authentication mechanism(s) without > further changes in Zookeeper code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2159) Pluggable SASL Authentication
Yuliya Feldman created ZOOKEEPER-2159: - Summary: Pluggable SASL Authentication Key: ZOOKEEPER-2159 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159 Project: ZooKeeper Issue Type: Improvement Components: java client, server Reporter: Yuliya Feldman Assignee: Yuliya Feldman Today SASLAuthenticationProvider is used for all SASL based authentications which creates some "if/else" statements in ZookeeperSaslClient and ZookeeperSaslServer code with just Kerberos and Digest. We want to use yet another different SASL based authentication and adding one more "if/else" with some code specific just to that new way does not make much sense. Proposal is to allow to plug custom SASL Authentication mechanism(s) without further changes in Zookeeper code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
