-Re: SASL problem with 3.4.4 Java client
Mahadev Konar 2012-09-26, 15:08
Thanks for digging. The explanation makes sense. Can you please open
a jira with the details?
On Wed, Sep 26, 2012 at 6:38 AM, Robert Macomber <[EMAIL PROTECTED]> wrote:
> On 2012-09-26, Mahadev Konar <[EMAIL PROTECTED]> wrote:
>> Thanks for point this out JL and Robert. We have a jira for this
>> https://issues.apache.org/jira/browse/ZOOKEEPER-1477 and we will be
>> doing a 3.4.5 ASAP to address this.
> This ticket doesn't look like it describes my problem. For me, it's
> OSX that works fine and Linux which does not, with rather different
> symptoms -- the client is explicitly deciding not to send any packets.
> I think I've tracked it down. In Linux,
> ZooKeeperSaslClient.clientTunneledAuthenticationInProgress is not
> receiving any SecurityException out of the call to
> javax.security.auth.login.Configuration.getConfiguration so that
> method thinks it's actually trying SASL. On OSX an exception is
> thrown and so the "Could not retrieve login configuration" log line is
> triggered. It looks like the constructor's idea of what constitutes
> "I'm going to do SASL" and the cTAIP method's idea differ a bit!
> Digging slightly further, the looks like it might be a difference
> between openjdk and the Oracle JVM rather than Linux/OSX. On openjdk,
> j.s.a.l.Configuration.getConfiguration succeeds on every system I've
> tried I've tried (admittedly all debian/ubuntu), but the Oracle JVM
> throws a SecurityException.
>> On Tue, Sep 25, 2012 at 3:37 PM, JL <[EMAIL PROTECTED]> wrote:
>>> This may be related. We are not using SSL, but the underlying cause may be the same: socket disconnection or failure to deliver data from the underlying channel.
>>> We experienced connection drops (after about ~3000ms) with Curator 1.1.18 and ZK 3.4.4. on openjdk 6 (on Linux), and JDK 7u7 on OS X.
>>> Oracle JVM 1.6.0_32 on Linux and v. 1.6.0_35 on OS X, seem to work.
>>> Here's the error we get over and over.
>>> E 09-25 17:01:35.408 http-bio-8081-exec-7-EventThread c.n.c.f.i.CuratorFrameworkImpl:486 :::] Background operation retry gave up
>>> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss
>>> at org.apache.zookeeper.KeeperException.create(KeeperException.java:99) ~[zookeeper-3.4.4.jar:3.4.4-1386507]
>>> at com.netflix.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(CuratorFrameworkImpl.java:448) ~[curator-framework-1.1.18.jar:na]
>>> at com.netflix.curator.framework.imps.BackgroundSyncImpl$1.processResult(BackgroundSyncImpl.java:49) [curator-framework-1.1.18.jar:na]
>>> at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:606) [zookeeper-3.4.4.jar:3.4.4-1386507]
>>> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) [zookeeper-3.4.4.jar:3.4.4-1386507]
>>> Sep 25, 2012 02:45:30 PM, [EMAIL PROTECTED] wrote:
>>> I'm having some trouble with the 3.4.4 Java client on Linux (openjdk 6
>>> or 7, debian or ubuntu). It doesn't seem to successfully connect to a
>>> server -- this goes for zkCli as well as custom code that uses the
>>> client jar. On OSX, it *does* connect.
>>> I've collected the DEBUG-level log output for the process of
>>> connecting to my development Zookeeper node (also running 3.4.4),
>>> waiting until a Connected event arrives, and sending getChildren("/").
>>> The Linux version logs that it will not use SASL and then keeps
>>> deferring the getChildren request "until SASL authentication
>>> completes". The exact same (fat) jar running on OSX complains a few
>>> times about being "unable to locate a login configuration" but doesn't
>>> Using the 3.4.3 client library or earlier does successfully connect,
>>> logging only the one message about JAAS that was changed as a result