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" <mohammad.ars...@huawei.com> 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 >
