Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
In-Reply-To: <D1D816F8.2804D%cnauroth@hortonworks.com>
References: 
 <OF52B60F02.6B3E3978-ON87257E8B.005D07B1-85257E8B.0060C7B0@us.ibm.com>
 <OF98A5DB1E.E71E6621-ON85257E8C.0007F752-85257E8C.00089698@us.ibm.com>
 <OF5F79E99B.D2BA4C07-ON85257E8C.005909C4-85257E8C.00595FDE@us.ibm.com>
 <D1D8048A.28008%cnauroth@hortonworks.com>
 <OFC3AC5082.38BA9B7F-ON85257E8C.007C17F3-85257E8C.007CC327@us.ibm.com>
 <D1D816F8.2804D%cnauroth@hortonworks.com>
To: user@zookeeper.apache.org
MIME-Version: 1.0
Subject: Re: ZooKeeper Class Will Not Connect
From: Chris Barlock <barlock@us.ibm.com>
Message-ID: 
 <OFE60B683C.016AEEE2-ON85257E8F.0064CB79-85257E8F.00653141@us.ibm.com>
Date: Mon, 27 Jul 2015 14:25:10 -0400
Content-Type: multipart/alternative;
 boundary="=_alternative 0065254B85257E8F_="

--=_alternative 0065254B85257E8F_=
Content-Type: text/plain; charset="US-ASCII"

Chris:

Your sample code works for me and I should be able to adapt it, but I 
still think there is a bug.  I made the following change to your sample to 
test my method:

    private Main(String hostPort) throws Exception {
        this.connectLatch = new CountDownLatch(1);
        waitTime = System.currentTimeMillis();
        this.zk = new ZooKeeper(hostPort, 3000, this);
 
        States state = zk.getState();
        while (state != States.CONNECTED) {
            System.out.println("State " + state);
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                System.out.println("Interrupted!");
            }
        }
    }

This outputs:

State CONNECTING
Received event: WatchedEvent state:SyncConnected type:None path:null
State CONNECTING
State CONNECTING
...

and zk.getState never returns anything but CONNECTING.  It seems that this 
started with ZK 3.4.3 as 3.4.2 works for me, but 3.4.3, 4, 5 and 6 all 
have this behavior in which the state is always CONNECTING.

Chris


From:   Chris Nauroth <cnauroth@hortonworks.com>
To:     "user@zookeeper.apache.org" <user@zookeeper.apache.org>
Date:   07/24/2015 07:28 PM
Subject:        Re: ZooKeeper Class Will Not Connect


ZooKeeper writes INFO-level logging about connection and session
establishment.  On the client side, these messages would come from the
ZooKeeper and ClientCnxn classes.  On the server side, these messages
would come from the ZooKeeperServer, NIOServerCnxn and NettyServerCnxn
classes.

It's possible that you could get more detail by turning up to DEBUG level
logging by adding these lines to log4j.properties for the client and
server respectively:

log4j.logger.org.apache.zookeeper=DEBUG
log4j.logger.org.apache.zookeeper.server=DEBUG


--Chris Nauroth


On 7/24/15, 3:42 PM, "Chris Barlock" <barlock@us.ibm.com> wrote:

>Chris:
>
>I have defined:
>
>    private static final int MAX_ZK_CONNECT_ATTEMPTS = 400;
> 
>    private static final long ZK_CONNECT_WAIT = 5; // Milliseconds
>
>so, two seconds, but I have also tried with ZK_CONNECT_WAIT = 500 (two
>hundred seconds).  getState always returned CONNECTING.  I can play with
>the async notification, but it really doesn't fit my application very
>well.  Is there any additional server or client tracing that can be
>enabled to get a better sense of what is going on?
>
>Chris
>
>IBM Tivoli Systems
>Research Triangle Park, NC
>(919) 224-2240
>Internet:  barlock@us.ibm.com
>
>
>
>From:   Chris Nauroth <cnauroth@hortonworks.com>
>To:     "user@zookeeper.apache.org" <user@zookeeper.apache.org>
>Date:   07/24/2015 06:19 PM
>Subject:        Re: ZooKeeper Class Will Not Connect
>
>
>
>Hello Chris,
>
>Thank you for the detailed repro steps describing which versions work and
>which versions don't work.  I tested your code sample against a 3.4.6
>build, and it worked consistently for me.  My only thought is that 
perhaps
>the MAX_ZK_CONNECT_ATTEMPTS and ZK_CONNECT_WAIT constants are set such
>that the polling loop exits before the connection completes.  Perhaps a
>subtle timing difference in the newer versions is just now exposing this.
>
>The typical pattern for connection establishment is to rely on the
>ZooKeeper client's asynchronous event notification instead of a polling
>loop.  See below for a code sample that initiates the connection and then
>waits for the SyncConnected event.  The ZooKeeper programmer's guide and
>example program docs have a more detailed discussion of this.
>
>http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html
>
>
>http://zookeeper.apache.org/doc/r3.4.6/javaExample.html
>
>
>Could you please try running this against your 3.4.6 cluster?  I'd be
>curious to see if the connection completes for you.  This would also give
>you a sense for how long connection establishment is taking and whether 
or
>not that's in line with your definitions of MAX_ZK_CONNECT_ATTEMPTS and
>ZK_CONNECT_WAIT.
>
>I hope this helps.
>
>
>
>class Main implements Watcher {
>
>    private final CountDownLatch connectLatch;
>    private final ZooKeeper zk;
>
>    public static void main(final String[] args) throws Exception {
>        String hostPort = args[0];
>        Main main = new Main(hostPort);
>        main.awaitConnection();
>        System.out.println("Exiting.");
>    }
>
>    private Main(String hostPort) throws Exception {
>        this.connectLatch = new CountDownLatch(1);
>        this.zk = new ZooKeeper(hostPort, 3000, this);
>    }
>
>    private void awaitConnection() throws InterruptedException {
>        this.connectLatch.await();
>        System.out.println("Connection has completed.");
>    }
>
>    @Override
>    public void process(WatchedEvent event) {
>        System.out.println("Received event: " + event);
>        if (event.getType() == Event.EventType.None) {
>            switch (event.getState()) {
>            case SyncConnected:
>                this.connectLatch.countDown();
>                break;
>            }
>        }
>    }
>}
>
>
>--Chris Nauroth
>
>
>
>
>On 7/24/15, 9:16 AM, "Chris Barlock" <barlock@us.ibm.com> wrote:
>
>>Ran some more tests.  My code works fine up through ZK 3.4.2, but then
>>fails with 3.4.3.  I did have to add the following to the Import-Package
>>list in the ZK MANIFEST.MF:
>>
>>org.slf4 j,javax.security.auth.login,javax.security.sasl
>>
>>I could really use some help here, ZK folks!  Is my code incorrect with
>>newer versions of ZK, or is ZK broken?
>>
>>Chris
>>
>>
>>
>>
>>
>>From:   Chris Barlock/Raleigh/IBM@IBMUS
>>To:     user@zookeeper.apache.org
>>Date:   07/23/2015 09:34 PM
>>Subject:        Re: ZooKeeper Class Will Not Connect
>>
>>
>>
>>I tried the 3.5.0 alpha build to see if it made any difference.  It did
>>not.
>>
>>But, I had to hack the MANIFEST.MF file in the JAR because the
>>"3.50-alpha" version fails tests in OSGi bundles that import the ZK
>>classes which have something like:
>>
>>version="[3.2,4)"
>>
>>I suggest that if you want to name the JAR "3.50-alpha" that all the
>>internals just use a version of 3.50.
>>
>>Chris
>>
>>IBM Tivoli Systems
>>Research Triangle Park, NC
>>(919) 224-2240
>>Internet:  barlock@us.ibm.com
>>
>>
>>
>>From:   Chris Barlock/Raleigh/IBM@IBMUS
>>To:     user@zookeeper.apache.org
>>Date:   07/23/2015 01:37 PM
>>Subject:        ZooKeeper Class Will Not Connect
>>
>>
>>
>>We are attempting to upgrade from Kafka 0.8.0, which includes ZK 3.3.4 
to
>>Kafka 0.8.2.1 with ZK 3.4.6.  My code which attempts to connect to ZK is
>>pretty straightforward:
>>
>>            try {
>>                ZooKeeper zk = new ZooKeeper(connectString,
>sessionTimeout
>>, this);
>>                int connectAttempts = 0;
>>
>>                while (!zk.getState().isConnected() && connectAttempts <
>>MAX_ZK_CONNECT_ATTEMPTS) {
>>                    try {
>>                        Thread.sleep(ZK_CONNECT_WAIT);
>>                    } catch (InterruptedException e) {
>>                        // Ignore
>>                    }
>>                    connectAttempts++;
>>                }
>>            } catch (IOException e) {
>>                trace.exception(CLASS_NAME, methodName, e);
>>            }
>>
>>With some additional tracing, States is always CONNECTING.  Has 
something
>>changed with 3.4.6 about how I should connect to the server?  I can
>>connect just fine with the zookeeper-shell.sh that Kafka ships.  This
>>code 
>>
>>
>>always runs on the same system as ZK, so the connectString is always
>>"localhost:2181"
>>
>>Chris
>>
>
>


--=_alternative 0065254B85257E8F_=--