Hi Pat, We didn't take up the changes from ZOOKEEPER-1497 yet and I believe we are still checking the existence of a system property to determine if SASL is configured. Eugene could confirm. Anyhow we have been testing with Oracle JRE 7 (u4 I believe was the most recent) so it seems we've had no exposure to ZOOKEEPER-1550 and tests have all been good.
Before ZOOKEEPER-1437 went in, when starting secure HBase regionservers up on EC2 test clusters, at one point most of the time they would lose the race, fail to authenticate, and abort. This was different from results on earlier versions (of HBase and from 3.4 branch), but because that timing problem was latent only then. On Wednesday, September 26, 2012, Patrick Hunt wrote: > On Wed, Sep 26, 2012 at 8:44 AM, Andrew Purtell > <[email protected]<javascript:;>> > wrote: > > Without ZOOKEEPER-1437 secure HBase is not functional in our environment. > > > > Hi Andrew, that's a good reason to not revert it then. > > I'd feel more comfortable if we had more feedback from users that > 3.4.4 is working (other than the noted issue) > > Andrew can you give us insight into your testing and how stable 3.4.4 > is for you? > > Patrick > > > On Wed, Sep 26, 2012 at 6:35 AM, Patrick Hunt <[email protected]> wrote: > >> How about if we revert > >> https://issues.apache.org/jira/browse/ZOOKEEPER-1437 and cut 3.4.5 RC0 > >> today? Robert, Julio, et. al. could help verify the "fix". We can > >> re-introduce 1437 in 3.4.6 and significantly reduce the risk until > >> that's had more time to bake (say cut 3.4.6 a few months down the > >> line). > >> > >> Patrick > >> > >> On Tue, Sep 25, 2012 at 10:05 PM, 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. > >>> > >>> 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 > >>>> of ZOOKEEPER-1510. > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
