zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2103) ZooKeeper Client Configuration
Date Mon, 04 Jul 2016 08:50:11 GMT

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

Hadoop QA commented on ZOOKEEPER-2103:
--------------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12690650/zookeeper-2103.patch
  against trunk revision 1750739.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 24 new or modified tests.

    -1 patch.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3260//console

This message is automatically generated.

> ZooKeeper Client Configuration
> ------------------------------
>
>                 Key: ZOOKEEPER-2103
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2103
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: java client
>    Affects Versions: 3.6.0
>         Environment: All
>            Reporter: Chris Larsen
>            Assignee: Chris Larsen
>            Priority: Minor
>              Labels: features, patch
>             Fix For: 3.6.0
>
>         Attachments: zookeeper-2103.patch
>
>
> I ran into an issue when connecting to two ZooKeeper clusters from the same JVM application.
One of the clusters required SASL authentication while the other one did not. Unfortunately
the client uses System properties to configure authentication and the client was attempting
to authenticate on the non-auth cluster, preventing a connection. 
> To solve it, I implemented a base config class with helper methods for parsing config
settings as well as a client specific subclass that parsed the system system values but allowed
for overriding via programatic values or via a file. There are also new Zookeeper constructors
to use this config object. I implemented it so that it's completely backwards compatible so
it shouldn't break existing installs (and it hasn't yet with my testing).
> If folks like this, we could use the same config base for server configs and migrate
away from system properties to per object configs. It would also be helpful to centralize
more of the "zookeeper.*" strings.
> Let me know what ya'll think and thanks!



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

Mime
View raw message