Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> SASL problem with 3.4.4 Java client

Copy link to this message
Re: SASL problem with 3.4.4 Java client
Hi Robert,
 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.
>> thanks
>> mahadev
>> 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]
>>> Cheers,
>>> -Julio
>>> 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
>>> wait.
>>> 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