You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by Wyatt Frelot <Wy...@altamiracorp.com> on 2015/02/02 21:58:07 UTC

Failed to connect to zookeeper within 2x ZK timeout period 30000

Good afternoon all,

I just literally started having this problem on Friday. My code worked previously (1mo ago) but I came back to it and I have not been able to resolve this problem since I have started experiencing it. So, I am seeking guidance and assistance.

I have a Vagrant cluster setup with the following environment:
Hadoop 2.4.1, ZK 3.3.6, Accumulo 1.6.1, and Java 7

I am able to ping the zookeeper node and there appears to be nothing in the ZK logs nor the Accumulo logs…I am not sure where to go from here.

This is the only error that I can find:

Exception in thread "main" org.apache.accumulo.core.client.AccumuloException: java.lang.RuntimeException: Failed to connect to zookeeper (mnode) within 2x zookeeper timeout period 30000
at org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:67)
at org.apache.accumulo.core.client.impl.ConnectorImpl.<init>(ConnectorImpl.java:70)
at org.apache.accumulo.core.client.ZooKeeperInstance.getConnector(ZooKeeperInstance.java:240)
at accumulo101.solutions.writing.TableAdministration.main(TableAdministration.java:66)
Caused by: java.lang.RuntimeException: Failed to connect to zookeeper (mnode) within 2x zookeeper timeout period 30000
at org.apache.accumulo.fate.zookeeper.ZooSession.connect(ZooSession.java:117)
at org.apache.accumulo.fate.zookeeper.ZooSession.getSession(ZooSession.java:161)
at org.apache.accumulo.fate.zookeeper.ZooReader.getSession(ZooReader.java:35)
at org.apache.accumulo.fate.zookeeper.ZooReader.getZooKeeper(ZooReader.java:39)
at org.apache.accumulo.fate.zookeeper.ZooCache.getZooKeeper(ZooCache.java:58)
at org.apache.accumulo.fate.zookeeper.ZooCache.retry(ZooCache.java:150)
at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:277)
at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:224)
at org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:161)
at org.apache.accumulo.core.zookeeper.ZooUtil.getRoot(ZooUtil.java:38)
at org.apache.accumulo.core.client.impl.ServerClient.getConnection(ServerClient.java:128)
at org.apache.accumulo.core.client.impl.ServerClient.getConnection(ServerClient.java:118)
at org.apache.accumulo.core.client.impl.ServerClient.getConnection(ServerClient.java:113)
at org.apache.accumulo.core.client.impl.ServerClient.executeRaw(ServerClient.java:95)
at org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:61)
... 3 more


Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Wyatt Frelot <Wy...@altamiracorp.com>.
I meant ZK 3.4.6.

Wyatt
On Feb 2, 2015, at 15:58, Wyatt Frelot <wy...@altamiracorp.com>> wrote:

Good afternoon all,

I just literally started having this problem on Friday. My code worked previously (1mo ago) but I came back to it and I have not been able to resolve this problem since I have started experiencing it. So, I am seeking guidance and assistance.

I have a Vagrant cluster setup with the following environment:
Hadoop 2.4.1, ZK 3.3.6, Accumulo 1.6.1, and Java 7

I am able to ping the zookeeper node and there appears to be nothing in the ZK logs nor the Accumulo logs…I am not sure where to go from here.

This is the only error that I can find:

Exception in thread "main" org.apache.accumulo.core.client.AccumuloException: java.lang.RuntimeException: Failed to connect to zookeeper (mnode) within 2x zookeeper timeout period 30000
at org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:67)
at org.apache.accumulo.core.client.impl.ConnectorImpl.<init>(ConnectorImpl.java:70)
at org.apache.accumulo.core.client.ZooKeeperInstance.getConnector(ZooKeeperInstance.java:240)
at accumulo101.solutions.writing.TableAdministration.main(TableAdministration.java:66)
Caused by: java.lang.RuntimeException: Failed to connect to zookeeper (mnode) within 2x zookeeper timeout period 30000
at org.apache.accumulo.fate.zookeeper.ZooSession.connect(ZooSession.java:117)
at org.apache.accumulo.fate.zookeeper.ZooSession.getSession(ZooSession.java:161)
at org.apache.accumulo.fate.zookeeper.ZooReader.getSession(ZooReader.java:35)
at org.apache.accumulo.fate.zookeeper.ZooReader.getZooKeeper(ZooReader.java:39)
at org.apache.accumulo.fate.zookeeper.ZooCache.getZooKeeper(ZooCache.java:58)
at org.apache.accumulo.fate.zookeeper.ZooCache.retry(ZooCache.java:150)
at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:277)
at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:224)
at org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:161)
at org.apache.accumulo.core.zookeeper.ZooUtil.getRoot(ZooUtil.java:38)
at org.apache.accumulo.core.client.impl.ServerClient.getConnection(ServerClient.java:128)
at org.apache.accumulo.core.client.impl.ServerClient.getConnection(ServerClient.java:118)
at org.apache.accumulo.core.client.impl.ServerClient.getConnection(ServerClient.java:113)
at org.apache.accumulo.core.client.impl.ServerClient.executeRaw(ServerClient.java:95)
at org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:61)
... 3 more



Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Wyatt Frelot <Wy...@altamiracorp.com>.
John,

Yes, I tried that and the same thing happens.

Sent from OWA on Android
________________________________
From: John Vines <vi...@apache.org>
Sent: Monday, February 2, 2015 5:03:04 PM
To: user@accumulo.apache.org
Subject: Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

I'm sorry, I meant nmode:2181 in your actual code.

On Mon, Feb 2, 2015 at 4:53 PM, Wyatt Frelot <Wy...@altamiracorp.com>> wrote:
John,

I think I did it right. Here is what I get when I  run it the way that you suggested.

vagrant@mnode:/cloud/accumulo/lib$ nc mnode:2181
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O length]
  [-P proxy_username] [-p source_port] [-q seconds] [-s source]
  [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
  [-x proxy_address[:port]] [destination] [port]


On Feb 2, 2015, at 16:38, John Vines <jv...@gmail.com>> wrote:

It looks like you're declaring your ZK connect string as "mnode". What happens if you do "mnode:2181"?

On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot <Wy...@altamiracorp.com>> wrote:
Mike

If I am reading this correctly, it appears as if everything is in order:

vagrant@mnode:/vagrant$ nc mnode 2181
stat
Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
Clients:
 /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
 /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
 /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
 /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
 /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
 /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
 /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
 /192.168.15.5:55564[1](queued=0,recved=88,sent=89)

Latency min/avg/max: 0/0/62
Received: 3114
Sent: 3162
Connections: 8
Outstanding: 0
Zxid: 0x71a
Mode: standalone
Node count: 270

Wyatt
On Feb 2, 2015, at 16:06, Mike Drob <md...@mdrob.com>> wrote:

nc [zk-host] [zk-port]

--
Cheers
~John



Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Wyatt Frelot <Wy...@altamiracorp.com>.
Good evening all,

Thanks for the replies. I found the problem. Somehow my /etc/hosts file was changed for the zookeeper node which was the issue.

Isolated the problem by swapping node name for IP address and started receiving Unknown Host errors which led me to the client’s etc/hosts file.

Thanks,

Wyatt
> On Feb 2, 2015, at 17:32, Josh Elser <el...@apache.org> wrote:
> 
> See swappiness: http://en.wikipedia.org/wiki/Swappiness
> 
> $ cat /proc/sys/vm/swappiness
> 
> # echo 20 > /proc/sys/vm/swappiness
> 
> tl;dr Having a "large" value for swappiness might cause the operating system to move your process to "swap" instead of main memory which would likely cause it to lose its ZooKeeper locks and die. The larger the value, the more aggressive the OS is in putting things to swap, the lower the value, the less so. It's not recommended to ever disable swap completely though.
> 
> Wyatt Frelot wrote:
>> I have been looking in the logs and I found something…just not sure about it’s impact:
>> 2015-02-02 22:21:04,390 [server.Accumulo] WARN : System swappiness setting is greater than ten (60) which can cause time-sensitive operations to be delayed. Accumulo is time sensitive because it needs to maintain distributed lock agreement.
>> 
>> Would this cause it?
>> 
>> Wyatt
>>> On Feb 2, 2015, at 17:03, John Vines <vines@apache.org <ma...@apache.org>> wrote:
>>> 
>>> I'm sorry, I meant nmode:2181 in your actual code.
>>> 
>>> On Mon, Feb 2, 2015 at 4:53 PM, Wyatt Frelot <Wyatt.Frelot@altamiracorp.com <ma...@altamiracorp.com>> wrote:
>>> 
>>>    John,
>>> 
>>>    I think I did it right. Here is what I get when I run it the way
>>>    that you suggested.
>>> 
>>>    vagrant@mnode:/cloud/accumulo/lib$ nc mnode:2181
>>>    This is nc from the netcat-openbsd package. An alternative nc is
>>>    available
>>>    in the netcat-traditional package.
>>>    usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O
>>>    length]
>>>    [-P proxy_username] [-p source_port] [-q seconds] [-s source]
>>>    [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
>>>    [-x proxy_address[:port]] [destination] [port]
>>> 
>>> 
>>>>    On Feb 2, 2015, at 16:38, John Vines <jvines@gmail.com
>>>>    <ma...@gmail.com>> wrote:
>>>> 
>>>>    It looks like you're declaring your ZK connect string as
>>>>    "mnode". What happens if you do "mnode:2181"?
>>>> 
>>>>    On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot
>>>>    <Wyatt.Frelot@altamiracorp.com
>>>>    <ma...@altamiracorp.com>> wrote:
>>>> 
>>>>        Mike
>>>> 
>>>>        If I am reading this correctly, it appears as if everything
>>>>        is in order:
>>>> 
>>>>        vagrant@mnode:/vagrant$ nc mnode 2181
>>>>        stat
>>>>        Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
>>>>        Clients:
>>>>        /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
>>>>        /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
>>>>        /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
>>>>        /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
>>>>        /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
>>>>        /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
>>>>        /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
>>>>        /192.168.15.5:55564[1](queued=0,recved=88,sent=89)
>>>> 
>>>>        Latency min/avg/max: 0/0/62
>>>>        Received: 3114
>>>>        Sent: 3162
>>>>        Connections: 8
>>>>        Outstanding: 0
>>>>        Zxid: 0x71a
>>>>        Mode: standalone
>>>>        Node count: 270
>>>> 
>>>>        Wyatt
>>>>>        On Feb 2, 2015, at 16:06, Mike Drob <mdrob@mdrob.com
>>>>>        <ma...@mdrob.com>> wrote:
>>>>> 
>>>>>        nc [zk-host] [zk-port]
>>>>> 
>>>>>        --         Cheers
>>>>>        ~John
>>>> 
>>> 
>>> 
>> 


Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Josh Elser <el...@apache.org>.
See swappiness: http://en.wikipedia.org/wiki/Swappiness

$ cat /proc/sys/vm/swappiness

# echo 20 > /proc/sys/vm/swappiness

tl;dr Having a "large" value for swappiness might cause the operating system to move your process to "swap" instead of main memory which would likely cause it to lose its ZooKeeper locks and die. The larger the value, the more aggressive the OS is in putting things to swap, the lower the value, the less so. It's not recommended to ever disable swap completely though.

Wyatt Frelot wrote:
> I have been looking in the logs and I found something…just not sure 
> about it’s impact:
> 2015-02-02 22:21:04,390 [server.Accumulo] WARN : System swappiness 
> setting is greater than ten (60) which can cause time-sensitive 
> operations to be delayed. Accumulo is time sensitive because it needs 
> to maintain distributed lock agreement.
>
> Would this cause it?
>
> Wyatt
>> On Feb 2, 2015, at 17:03, John Vines <vines@apache.org 
>> <ma...@apache.org>> wrote:
>>
>> I'm sorry, I meant nmode:2181 in your actual code.
>>
>> On Mon, Feb 2, 2015 at 4:53 PM, Wyatt Frelot 
>> <Wyatt.Frelot@altamiracorp.com 
>> <ma...@altamiracorp.com>> wrote:
>>
>>     John,
>>
>>     I think I did it right. Here is what I get when I run it the way
>>     that you suggested.
>>
>>     vagrant@mnode:/cloud/accumulo/lib$ nc mnode:2181
>>     This is nc from the netcat-openbsd package. An alternative nc is
>>     available
>>     in the netcat-traditional package.
>>     usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O
>>     length]
>>     [-P proxy_username] [-p source_port] [-q seconds] [-s source]
>>     [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
>>     [-x proxy_address[:port]] [destination] [port]
>>
>>
>>>     On Feb 2, 2015, at 16:38, John Vines <jvines@gmail.com
>>>     <ma...@gmail.com>> wrote:
>>>
>>>     It looks like you're declaring your ZK connect string as
>>>     "mnode". What happens if you do "mnode:2181"?
>>>
>>>     On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot
>>>     <Wyatt.Frelot@altamiracorp.com
>>>     <ma...@altamiracorp.com>> wrote:
>>>
>>>         Mike
>>>
>>>         If I am reading this correctly, it appears as if everything
>>>         is in order:
>>>
>>>         vagrant@mnode:/vagrant$ nc mnode 2181
>>>         stat
>>>         Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
>>>         Clients:
>>>         /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
>>>         /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
>>>         /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
>>>         /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
>>>         /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
>>>         /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
>>>         /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
>>>         /192.168.15.5:55564[1](queued=0,recved=88,sent=89)
>>>
>>>         Latency min/avg/max: 0/0/62
>>>         Received: 3114
>>>         Sent: 3162
>>>         Connections: 8
>>>         Outstanding: 0
>>>         Zxid: 0x71a
>>>         Mode: standalone
>>>         Node count: 270
>>>
>>>         Wyatt
>>>>         On Feb 2, 2015, at 16:06, Mike Drob <mdrob@mdrob.com
>>>>         <ma...@mdrob.com>> wrote:
>>>>
>>>>         nc [zk-host] [zk-port]
>>>>
>>>>         -- 
>>>>         Cheers
>>>>         ~John
>>>
>>
>>
>

Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Wyatt Frelot <Wy...@altamiracorp.com>.
I have been looking in the logs and I found something…just not sure about it’s impact:
2015-02-02 22:21:04,390 [server.Accumulo] WARN : System swappiness setting is greater than ten (60) which can cause time-sensitive operations to be delayed.  Accumulo is time sensitive because it needs to maintain distributed lock agreement.

Would this cause it?

Wyatt
On Feb 2, 2015, at 17:03, John Vines <vi...@apache.org>> wrote:

I'm sorry, I meant nmode:2181 in your actual code.

On Mon, Feb 2, 2015 at 4:53 PM, Wyatt Frelot <Wy...@altamiracorp.com>> wrote:
John,

I think I did it right. Here is what I get when I  run it the way that you suggested.

vagrant@mnode:/cloud/accumulo/lib$ nc mnode:2181
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O length]
  [-P proxy_username] [-p source_port] [-q seconds] [-s source]
  [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
  [-x proxy_address[:port]] [destination] [port]


On Feb 2, 2015, at 16:38, John Vines <jv...@gmail.com>> wrote:

It looks like you're declaring your ZK connect string as "mnode". What happens if you do "mnode:2181"?

On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot <Wy...@altamiracorp.com>> wrote:
Mike

If I am reading this correctly, it appears as if everything is in order:

vagrant@mnode:/vagrant$ nc mnode 2181
stat
Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
Clients:
 /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
 /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
 /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
 /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
 /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
 /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
 /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
 /192.168.15.5:55564[1](queued=0,recved=88,sent=89)

Latency min/avg/max: 0/0/62
Received: 3114
Sent: 3162
Connections: 8
Outstanding: 0
Zxid: 0x71a
Mode: standalone
Node count: 270

Wyatt
On Feb 2, 2015, at 16:06, Mike Drob <md...@mdrob.com>> wrote:

nc [zk-host] [zk-port]

--
Cheers
~John




Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by John Vines <vi...@apache.org>.
I'm sorry, I meant nmode:2181 in your actual code.

On Mon, Feb 2, 2015 at 4:53 PM, Wyatt Frelot <Wy...@altamiracorp.com>
wrote:

>  John,
>
>  I think I did it right. Here is what I get when I  run it the way that
> you suggested.
>
>  vagrant@mnode:/cloud/accumulo/lib$ nc mnode:2181
> This is nc from the netcat-openbsd package. An alternative nc is available
> in the netcat-traditional package.
> usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O length]
>   [-P proxy_username] [-p source_port] [-q seconds] [-s source]
>   [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
>   [-x proxy_address[:port]] [destination] [port]
>
>
>   On Feb 2, 2015, at 16:38, John Vines <jv...@gmail.com> wrote:
>
>  It looks like you're declaring your ZK connect string as "mnode". What
> happens if you do "mnode:2181"?
>
> On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot <
> Wyatt.Frelot@altamiracorp.com> wrote:
>
>> Mike
>>
>>  If I am reading this correctly, it appears as if everything is in order:
>>
>>  vagrant@mnode:/vagrant$ nc mnode 2181
>> stat
>> Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
>> Clients:
>>  /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
>>  /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
>>  /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
>>  /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
>>  /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
>>  /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
>>  /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
>>  /192.168.15.5:55564[1](queued=0,recved=88,sent=89)
>>
>>  Latency min/avg/max: 0/0/62
>> Received: 3114
>> Sent: 3162
>> Connections: 8
>> Outstanding: 0
>> Zxid: 0x71a
>> Mode: standalone
>> Node count: 270
>>
>>  Wyatt
>>
>> On Feb 2, 2015, at 16:06, Mike Drob <md...@mdrob.com> wrote:
>>
>> nc [zk-host] [zk-port]
>>
>>  --
>>  Cheers
>> ~John
>>
>>
>

Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Wyatt Frelot <Wy...@altamiracorp.com>.
John,

I think I did it right. Here is what I get when I  run it the way that you suggested.

vagrant@mnode:/cloud/accumulo/lib$ nc mnode:2181
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46bCDdhjklnrStUuvZz] [-I length] [-i interval] [-O length]
  [-P proxy_username] [-p source_port] [-q seconds] [-s source]
  [-T toskeyword] [-V rtable] [-w timeout] [-X proxy_protocol]
  [-x proxy_address[:port]] [destination] [port]


On Feb 2, 2015, at 16:38, John Vines <jv...@gmail.com>> wrote:

It looks like you're declaring your ZK connect string as "mnode". What happens if you do "mnode:2181"?

On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot <Wy...@altamiracorp.com>> wrote:
Mike

If I am reading this correctly, it appears as if everything is in order:

vagrant@mnode:/vagrant$ nc mnode 2181
stat
Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
Clients:
 /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
 /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
 /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
 /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
 /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
 /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
 /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
 /192.168.15.5:55564[1](queued=0,recved=88,sent=89)

Latency min/avg/max: 0/0/62
Received: 3114
Sent: 3162
Connections: 8
Outstanding: 0
Zxid: 0x71a
Mode: standalone
Node count: 270

Wyatt
On Feb 2, 2015, at 16:06, Mike Drob <md...@mdrob.com>> wrote:

nc [zk-host] [zk-port]

--
Cheers
~John


Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by John Vines <jv...@gmail.com>.
It looks like you're declaring your ZK connect string as "mnode". What
happens if you do "mnode:2181"?

On Mon, Feb 2, 2015 at 4:17 PM, Wyatt Frelot <Wy...@altamiracorp.com>
wrote:

>  Mike
>
>  If I am reading this correctly, it appears as if everything is in order:
>
>  vagrant@mnode:/vagrant$ nc mnode 2181
> stat
> Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
> Clients:
>  /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
>  /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
>  /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
>  /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
>  /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
>  /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
>  /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
>  /192.168.15.5:55564[1](queued=0,recved=88,sent=89)
>
>  Latency min/avg/max: 0/0/62
> Received: 3114
> Sent: 3162
> Connections: 8
> Outstanding: 0
> Zxid: 0x71a
> Mode: standalone
> Node count: 270
>
>  Wyatt
>
> On Feb 2, 2015, at 16:06, Mike Drob <md...@mdrob.com> wrote:
>
> nc [zk-host] [zk-port]
>
> --
> Cheers
> ~John
>
>

Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Wyatt Frelot <Wy...@altamiracorp.com>.
Mike

If I am reading this correctly, it appears as if everything is in order:

vagrant@mnode:/vagrant$ nc mnode 2181
stat
Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
Clients:
 /192.168.15.4:44488[1](queued=0,recved=84,sent=85)
 /192.168.15.2:48504[0](queued=0,recved=1,sent=0)
 /192.168.15.2:48262[1](queued=0,recved=1577,sent=1598)
 /192.168.15.5:55540[1](queued=0,recved=434,sent=449)
 /192.168.15.3:37401[1](queued=0,recved=236,sent=239)
 /192.168.15.4:44480[1](queued=0,recved=244,sent=251)
 /192.168.15.5:55559[1](queued=0,recved=100,sent=101)
 /192.168.15.5:55564[1](queued=0,recved=88,sent=89)

Latency min/avg/max: 0/0/62
Received: 3114
Sent: 3162
Connections: 8
Outstanding: 0
Zxid: 0x71a
Mode: standalone
Node count: 270

Wyatt
On Feb 2, 2015, at 16:06, Mike Drob <md...@mdrob.com>> wrote:

nc [zk-host] [zk-port]


Re: Failed to connect to zookeeper within 2x ZK timeout period 30000

Posted by Mike Drob <md...@mdrob.com>.
Can you verify that zookeeper is running and accepting connections?

nc [zk-host] [zk-port]
> stat

And see that it does not result in error.

On Mon, Feb 2, 2015 at 2:58 PM, Wyatt Frelot <Wy...@altamiracorp.com>
wrote:

>  Good afternoon all,
>
>  I just literally started having this problem on Friday. My code worked
> previously (1mo ago) but I came back to it and I have not been able to
> resolve this problem since I have started experiencing it. So, I am seeking
> guidance and assistance.
>
>  I have a Vagrant cluster setup with the following environment:
> Hadoop 2.4.1, ZK 3.3.6, Accumulo 1.6.1, and Java 7
>
>  I am able to ping the zookeeper node and there appears to be nothing in
> the ZK logs nor the Accumulo logs…I am not sure where to go from here.
>
>  This is the only error that I can find:
>
>  Exception in thread "main"
> org.apache.accumulo.core.client.AccumuloException:
> java.lang.RuntimeException: Failed to connect to zookeeper (mnode) within
> 2x zookeeper timeout period 30000
>  at org.apache.accumulo.core.client.impl.ServerClient.execute(
> ServerClient.java:67)
>  at org.apache.accumulo.core.client.impl.ConnectorImpl.<init>(
> ConnectorImpl.java:70)
>  at org.apache.accumulo.core.client.ZooKeeperInstance.getConnector(
> ZooKeeperInstance.java:240)
>  at accumulo101.solutions.writing.TableAdministration.main(
> TableAdministration.java:66)
>  Caused by: java.lang.RuntimeException: Failed to connect to zookeeper
> (mnode) within 2x zookeeper timeout period 30000
>  at org.apache.accumulo.fate.zookeeper.ZooSession.connect(
> ZooSession.java:117)
>  at org.apache.accumulo.fate.zookeeper.ZooSession.getSession(
> ZooSession.java:161)
>  at org.apache.accumulo.fate.zookeeper.ZooReader.getSession(
> ZooReader.java:35)
>  at org.apache.accumulo.fate.zookeeper.ZooReader.getZooKeeper(
> ZooReader.java:39)
>  at org.apache.accumulo.fate.zookeeper.ZooCache.getZooKeeper(
> ZooCache.java:58)
>  at org.apache.accumulo.fate.zookeeper.ZooCache.retry(ZooCache.java:150)
>  at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:277)
>  at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:224)
>  at org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(
> ZooKeeperInstance.java:161)
>  at org.apache.accumulo.core.zookeeper.ZooUtil.getRoot(ZooUtil.java:38)
>  at org.apache.accumulo.core.client.impl.ServerClient.getConnection(
> ServerClient.java:128)
>  at org.apache.accumulo.core.client.impl.ServerClient.getConnection(
> ServerClient.java:118)
>  at org.apache.accumulo.core.client.impl.ServerClient.getConnection(
> ServerClient.java:113)
>  at org.apache.accumulo.core.client.impl.ServerClient.executeRaw(
> ServerClient.java:95)
>  at org.apache.accumulo.core.client.impl.ServerClient.execute(
> ServerClient.java:61)
>  ... 3 more
>
>