ZooKeeper
  1. ZooKeeper
  2. ZOOKEEPER-1696

Fail to run zookeeper client on Weblogic application server

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.4.5
    • Fix Version/s: 3.4.6, 3.5.0
    • Component/s: java client
    • Labels:
      None
    • Environment:

      Java version: jdk170_06
      WebLogic Server Version: 10.3.6.0

      Description

      The problem in details is described here: http://comments.gmane.org/gmane.comp.java.zookeeper.user/2897
      The provided link also contains a reference to fix implementation.

      ####<Apr 24, 2013 1:03:28 PM MSK> <Warning> <org.apache.zookeeper.ClientCnxn> <devapp090> <clust2> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (devapp090:2182)> <internal> <> <> <1366794208810> <BEA-000000> <WARN  org.apache.zookeeper.ClientCnxn - Session 0x0 for server null, unexpected error, closing socket connection and attempting reconnect
      java.lang.IllegalArgumentException: No Configuration was registered that can handle the configuration named Client
                      at com.bea.common.security.jdkutils.JAASConfiguration.getAppConfigurationEntry(JAASConfiguration.java:130)
                      at org.apache.zookeeper.client.ZooKeeperSaslClient.<init>(ZooKeeperSaslClient.java:97)
                      at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:943)
                      at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:993)
      >
      
      
      1. zookeeper-1696.patch
        5 kB
        Jeffrey Zhong
      2. zookeeper-1696-v1.patch
        5 kB
        Jeffrey Zhong
      3. zookeeper-1696-v2.patch
        5 kB
        Jeffrey Zhong

        Issue Links

          Activity

          Hide
          Flavio Junqueira added a comment -

          Closing issues after releasing 3.4.6.

          Show
          Flavio Junqueira added a comment - Closing issues after releasing 3.4.6.
          Hide
          Hudson added a comment -

          SUCCESS: Integrated in ZooKeeper-trunk #2070 (See https://builds.apache.org/job/ZooKeeper-trunk/2070/)
          ZOOKEEPER-1696. Fail to run zookeeper client on Weblogic application server. (Jeffrey Zhong via mahade (mahadev: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1527129)

          Show
          Hudson added a comment - SUCCESS: Integrated in ZooKeeper-trunk #2070 (See https://builds.apache.org/job/ZooKeeper-trunk/2070/ ) ZOOKEEPER-1696 . Fail to run zookeeper client on Weblogic application server. (Jeffrey Zhong via mahade (mahadev: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1527129 ) /zookeeper/trunk/CHANGES.txt /zookeeper/trunk/src/java/main/org/apache/zookeeper/client/ZooKeeperSaslClient.java Reverting ZOOKEEPER-1696 patch that was committed. (mahadev: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1527122 ) /zookeeper/trunk/CHANGES.txt /zookeeper/trunk/src/java/main/org/apache/zookeeper/client/ZooKeeperSaslClient.java
          Hide
          Mahadev konar added a comment -

          Committed the right patch. Thanks Jeffrey!

          Show
          Mahadev konar added a comment - Committed the right patch. Thanks Jeffrey!
          Hide
          Mahadev konar added a comment -

          Reopening looks like I committed the wrong patch.

          Show
          Mahadev konar added a comment - Reopening looks like I committed the wrong patch.
          Hide
          Hudson added a comment -

          SUCCESS: Integrated in ZooKeeper-trunk #2068 (See https://builds.apache.org/job/ZooKeeper-trunk/2068/)
          ZOOKEEPER-1696. Fail to run zookeeper client on Weblogic application server. (Jeffrey Zhong via mahade. (mahadev: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1526337)

          • /zookeeper/trunk/CHANGES.txt
          • /zookeeper/trunk/src/java/main/org/apache/zookeeper/client/ZooKeeperSaslClient.java
          Show
          Hudson added a comment - SUCCESS: Integrated in ZooKeeper-trunk #2068 (See https://builds.apache.org/job/ZooKeeper-trunk/2068/ ) ZOOKEEPER-1696 . Fail to run zookeeper client on Weblogic application server. (Jeffrey Zhong via mahade. (mahadev: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1526337 ) /zookeeper/trunk/CHANGES.txt /zookeeper/trunk/src/java/main/org/apache/zookeeper/client/ZooKeeperSaslClient.java
          Hide
          Mahadev konar added a comment -

          Thanks Jeffrey. Just committed this to trunk and branch-3.4.

          Show
          Mahadev konar added a comment - Thanks Jeffrey. Just committed this to trunk and branch-3.4.
          Hide
          Flavio Junqueira added a comment -

          Thanks for bearing with me, Jeffrey Zhong. It looks good to me now.

          Show
          Flavio Junqueira added a comment - Thanks for bearing with me, Jeffrey Zhong . It looks good to me now.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12604691/zookeeper-1696-v2.patch
          against trunk revision 1524398.

          +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 1.3.9) 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/1597//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1597//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1597//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12604691/zookeeper-1696-v2.patch against trunk revision 1524398. +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 1.3.9) 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/1597//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1597//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1597//console This message is automatically generated.
          Hide
          Jeffrey Zhong added a comment -

          Flavio Junqueira Ok. In the v2 patch, only Security(existing) and IllegalArgumentException are handled without catching other types of runtime exception to be conservative for now. Thanks.

          Show
          Jeffrey Zhong added a comment - Flavio Junqueira Ok. In the v2 patch, only Security(existing) and IllegalArgumentException are handled without catching other types of runtime exception to be conservative for now. Thanks.
          Hide
          Flavio Junqueira added a comment -

          Thanks for uploading a new patch, Jeffrey. I just realized that my comment was a bit ambiguous. I was actually proposing to catch security exception and illegal argument exception, rather than security exception and runtime exception. Are you also ok with security and illegal argument?

          Show
          Flavio Junqueira added a comment - Thanks for uploading a new patch, Jeffrey. I just realized that my comment was a bit ambiguous. I was actually proposing to catch security exception and illegal argument exception, rather than security exception and runtime exception. Are you also ok with security and illegal argument?
          Hide
          Jeffrey Zhong added a comment -

          Incorporate Flavio Junqueira's comments to catch security & runtime exception separately into v1 patch. Thanks.

          Show
          Jeffrey Zhong added a comment - Incorporate Flavio Junqueira 's comments to catch security & runtime exception separately into v1 patch. Thanks.
          Hide
          Jeffrey Zhong added a comment -

          I'd rather catch both explicitly instead of catching runtime exception, to be conservative with respect to the exceptions we catch and for readability.

          That's a good point. Let me make a updated patch. Thanks.

          Show
          Jeffrey Zhong added a comment - I'd rather catch both explicitly instead of catching runtime exception, to be conservative with respect to the exceptions we catch and for readability. That's a good point. Let me make a updated patch. Thanks.
          Hide
          Flavio Junqueira added a comment -

          Ok, got it. My understanding is that one reason for proposing that we catch runtime exception because we also need to catch security exception. I'd rather catch both explicitly instead of catching runtime exception, to be conservative with respect to the exceptions we catch and for readability. Another reason seems to be that other applications might throw a different exception. Given that we don't know what other applications will do, I'd rather not speculate. Does it sound reasonable?

          Show
          Flavio Junqueira added a comment - Ok, got it. My understanding is that one reason for proposing that we catch runtime exception because we also need to catch security exception. I'd rather catch both explicitly instead of catching runtime exception, to be conservative with respect to the exceptions we catch and for readability. Another reason seems to be that other applications might throw a different exception. Given that we don't know what other applications will do, I'd rather not speculate. Does it sound reasonable?
          Hide
          Jeffrey Zhong added a comment -

          First, what's the precise reason for not being able to reliably determine if SASL is set

          Seems to me there is no other exposed API to check if SASL is set instead of the getAppConfigurationEntry. The IllegalArgumentException is thrown from BEA com.bea.common.security.jdkutils.JAASConfiguration.getAppConfigurationEntry code. In other words, if other third party code decides to throw different exceptions then we have to fix the same issue again.

          Show
          Jeffrey Zhong added a comment - First, what's the precise reason for not being able to reliably determine if SASL is set Seems to me there is no other exposed API to check if SASL is set instead of the getAppConfigurationEntry. The IllegalArgumentException is thrown from BEA com.bea.common.security.jdkutils.JAASConfiguration.getAppConfigurationEntry code. In other words, if other third party code decides to throw different exceptions then we have to fix the same issue again.
          Hide
          Flavio Junqueira added a comment -

          I haven't thought too deeply about this issue, so if you guys could help me out here, I would appreciate it. First, what's the precise reason for not being able to reliably determine if SASL is set? Second, in the case we need to catch a runtime exception, can we catch illegal argument exception instead of runtime?

          Show
          Flavio Junqueira added a comment - I haven't thought too deeply about this issue, so if you guys could help me out here, I would appreciate it. First, what's the precise reason for not being able to reliably determine if SASL is set? Second, in the case we need to catch a runtime exception, can we catch illegal argument exception instead of runtime?
          Hide
          Jeffrey Zhong added a comment -

          Flavio Junqueira It seems the patch for this JIRA also addresses the ZOOKEEPER-1554. Once it detects that SASL isn't configured, we have the following code in function to prevent the issue of ZOOKEEPER-1554 from happening. Thanks.

          public boolean clientTunneledAuthenticationInProgress() {
          +    	if (!isSASLConfigured) {
          +    	    return false;
          +        }
          
          Show
          Jeffrey Zhong added a comment - Flavio Junqueira It seems the patch for this JIRA also addresses the ZOOKEEPER-1554 . Once it detects that SASL isn't configured, we have the following code in function to prevent the issue of ZOOKEEPER-1554 from happening. Thanks. public boolean clientTunneledAuthenticationInProgress() { + if (!isSASLConfigured) { + return false ; + }
          Hide
          Flavio Junqueira added a comment -

          I don't see a problem with this one getting in, but I was wondering about ZOOKEEPER-1554, if it needs to get in as well, and if this one impacts ZOOKEEPER-1657 at all.

          Show
          Flavio Junqueira added a comment - I don't see a problem with this one getting in, but I was wondering about ZOOKEEPER-1554 , if it needs to get in as well, and if this one impacts ZOOKEEPER-1657 at all.
          Hide
          Mahadev konar added a comment - - edited

          +1 for the patch. Given it ran through jenkins we can commit this to 3.4 and trunk.

          Show
          Mahadev konar added a comment - - edited +1 for the patch. Given it ran through jenkins we can commit this to 3.4 and trunk.
          Hide
          Mahadev konar added a comment -

          The same patch applies to 3.4 and trunk.

          Show
          Mahadev konar added a comment - The same patch applies to 3.4 and trunk.
          Hide
          Mahadev konar added a comment -

          Running the zk unit tests again. Flavio Junqueira do you see any issues this going into 3.4.6 release? Thsi is a good change to have and is causing ZK embedding to cause issues in web logic.

          Show
          Mahadev konar added a comment - Running the zk unit tests again. Flavio Junqueira do you see any issues this going into 3.4.6 release? Thsi is a good change to have and is causing ZK embedding to cause issues in web logic.
          Hide
          Hadoop QA added a comment -

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

          +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 1.3.9) 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/1583//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1583//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1583//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12597225/zookeeper-1696.patch against trunk revision 1522079. +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 1.3.9) 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/1583//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1583//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1583//console This message is automatically generated.
          Hide
          Jeffrey Zhong added a comment -

          I've submitted a patch which worked in tests for the issue. Let me know if you have better idea. Thanks.

          Show
          Jeffrey Zhong added a comment - I've submitted a patch which worked in tests for the issue. Let me know if you have better idea. Thanks.
          Hide
          Jeffrey Zhong added a comment -

          Since there is no reliable way to determine if SASL setting is set, the patch catches RuntimeException to see if SASL setting is configured. Please let me know if there is any better way.

          Show
          Jeffrey Zhong added a comment - Since there is no reliable way to determine if SASL setting is set, the patch catches RuntimeException to see if SASL setting is configured. Please let me know if there is any better way.
          Hide
          Dmitry Konstantinov added a comment -
          Show
          Dmitry Konstantinov added a comment - We use the patch is described here ( http://comments.gmane.org/gmane.comp.java.zookeeper.user/2897 , https://gist.github.com/barkbay/4153107 ), it works in Weblogic
          Hide
          Kevin Wang added a comment -

          I got the same issue for a long time, anyone konws how to solve it?

          Show
          Kevin Wang added a comment - I got the same issue for a long time, anyone konws how to solve it?
          Hide
          Eugene Kalinin added a comment -

          I've got approximately the same case under the JBoss AS 7.1.1.Final.

          Show
          Eugene Kalinin added a comment - I've got approximately the same case under the JBoss AS 7.1.1.Final.

            People

            • Assignee:
              Jeffrey Zhong
              Reporter:
              Dmitry Konstantinov
            • Votes:
              6 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development