Re: Login object in ZooKeeperSaslClient

[Chris Nauroth]

I don't know the history for certain, but some of the comments on
ZOOKEEPER-938 make it look like the ZooKeeper implementation looked at the
Hadoop implementation for inspiration.  Hadoop's UserGroupInformation
class has a notion of the "login user", which similarly translates to a
static Subject/LoginContext instance representing the "identity of the
process".  Over time, the Hadoop community has realized that this causes
difficulties for all the usual reasons that statics/global state can
cause.  Perhaps the static Login in ZooKeeperSaslClient is not so much an
intentional design choice, but rather a duplication of a design choice
from Hadoop, and a design choice that has turned out to be problematic in
some ways after a few years of hindsight.

+1 for the proposal to move away from static.  I haven't looked at the
patches yet, but backwards-compatibility might be an interesting
consideration, since current usage may have an expectation of a global
authenticated subject.

--Chris Nauroth




On 3/22/16, 10:58 PM, "Mohammad arshad"  wrote:

>I think login object is static to achieve some optimization in refreshing
>the TGT. Currently multiple ZooKeeper client can run in one JVM but all
>must share same configuration, principal. Because all the clients share
>same principal, one login object is enough to serve the purpose.
>
>There are many things which cannot be done without making the login
>object not static. some are
>1) Multiple ZooKeeper clients in a single JVM each having different
>principals, must have separate login object, more detail in ZOOKEEPER-2139
>2) Cannot close TGT refresh thread in login object on close of
>ZooKeeper.close() API call, more detail in ZOOKEEPER-2330
>
>I am +1 for making login object in ZooKeeperSaslClient non static
>
>Best Regards
>Arshad
>
>-Original Message-
>From: Flavio Junqueira [mailto:f...@apache.org]
>Sent: 23 March 2016 03:22
>To: Zookeeper
>Subject: Login object in ZooKeeperSaslClient
>
>Hello,
>
>I've been looking at the ZooKeeperSaslClient class, and I've been
>wondering why the Login object is static in that class. Is it only to
>avoid having one login thread for each concurrent session? I'd like to
>make it non-static because this way we can have multiple handles in the
>same jvm using different configurations. We'd also need to pass the login
>configuration separately.
>
>I had a look at the ZOOKEEPER-938 jira for some insight, but couldn't get
>any. Any other insight here would be great.
>
>-Flavio
>

RE: Login object in ZooKeeperSaslClient

[Mohammad arshad]

I think login object is static to achieve some optimization in refreshing the 
TGT. Currently multiple ZooKeeper client can run in one JVM but all must share 
same configuration, principal. Because all the clients share same principal, 
one login object is enough to serve the purpose.

There are many things which cannot be done without making the login object not 
static. some are
1) Multiple ZooKeeper clients in a single JVM each having different principals, 
must have separate login object, more detail in ZOOKEEPER-2139
2) Cannot close TGT refresh thread in login object on close of 
ZooKeeper.close() API call, more detail in ZOOKEEPER-2330

I am +1 for making login object in ZooKeeperSaslClient non static

Best Regards
Arshad

-Original Message-
From: Flavio Junqueira [mailto:f...@apache.org] 
Sent: 23 March 2016 03:22
To: Zookeeper
Subject: Login object in ZooKeeperSaslClient

Hello,

I've been looking at the ZooKeeperSaslClient class, and I've been wondering why 
the Login object is static in that class. Is it only to avoid having one login 
thread for each concurrent session? I'd like to make it non-static because this 
way we can have multiple handles in the same jvm using different 
configurations. We'd also need to pass the login configuration separately.

I had a look at the ZOOKEEPER-938 jira for some insight, but couldn't get any. 
Any other insight here would be great.

-Flavio