[ https://issues.apache.org/jira/browse/ZOOKEEPER-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kuba Skopal resolved ZOOKEEPER-1764. ------------------------------------ Resolution: Implemented Fix Version/s: 3.4.6 Release Note: Solved by ZOOKEEPER-1657 > ZooKeeper attempts at SASL eventhough it shouldn't > -------------------------------------------------- > > Key: ZOOKEEPER-1764 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1764 > Project: ZooKeeper > Issue Type: Bug > Components: java client > Affects Versions: 3.4.4 > Reporter: Kuba Skopal > Fix For: 3.4.6 > > > We are using a proprietary SASL solution, but we don't want to use it with > ZooKeeper. Unfortunately it seems, that there is no way to disable SASL for > ZooKeeper as the code only checks for presence of > "java.security.auth.login.config" system property to determine whether SASL > should be used or not. > For us it means, that ZooKeeper client just shuts down after SASL is > initialized. What happens: > 1) System.getProperty("java.security.auth.login.config") is initially null > 2) ZooKeeper is initialized and used > 3) Our JAAS/SASL component is initialized > 4) System.getProperty("java.security.auth.login.config") is not null anymore > 5) ZooKeeperSaslClient.clientTunneledAuthenticationInProgress() suddenly > picks up the new property and starts returning true > 6) ClientCnxnSocketNIO.findSendablePacket() suddenly stops returning any > packets since clientTunneledAuthenticationInProgress is always true > The communication is halted and eventually times out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira