curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cameron McKenzie (JIRA)" <>
Subject [jira] [Commented] (CURATOR-172) Deadlock when performing background operation
Date Mon, 15 Dec 2014 23:10:13 GMT


Cameron McKenzie commented on CURATOR-172:

I've had a bit of a look through the code and I think that your theory on what's happening
is correct. For whatever reason the ZK connection cannot finish sending / receiving the packet,
which in turn means that the checkTimeouts() method gets blocked indefinitely. So, I'm not
exactly sure if this is a problem with Curator or a problem with ZK. 

I would presume that ZK doesn't just read indefinitely waiting for a response for the packet
that it sent, and there shouldn't be any interaction between the Curator synchronization and
the ZK synchronization, so I'm really not sure.

> Deadlock when performing background operation
> ---------------------------------------------
>                 Key: CURATOR-172
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 2.4.2
>         Environment: Linux HOSTNAME-REMOVED 2.6.32-279.19.1.el6.x86_64 #1 SMP Tue Dec
18 15:04:44 PST 2012 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_60"
> Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
> Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
>            Reporter: Tom Byrne
> Had a box get into a state where our ZK connections were all deadlocked, waiting on an
object monitor. jstack shows that our background thread that was creating a node was waiting
on a lock that was held by the CuratorFramework thread, who was waiting on an object monitor
that looks like it couldn't be completed until our other write was finished (packet.finish
would never return true.) 
> We have seen this happen twice, but don't notice it until afterwards, and don't have
enough logging to know what's triggering it (possible ZK connections going away?) 
> Rest of the box is fine, network connections are not flapping, main IO threads continue
to accept and process connections, until we get backed up waiting for ZK. 
> Here are the two stack traces:
> "ZooChangeWatcher-BackgroundReader--2-1-SendThread()" daemon prio=10 tid=0x00007fcf64108000
nid=0x88d waiting for monitor entry [0x00007fcbf5d16000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.apache.curator.ConnectionState.checkTimeouts(
> 	- waiting to lock <0x00000000d526bcc8> (a org.apache.curator.ConnectionState)
> 	at org.apache.curator.ConnectionState.getZooKeeper(
> 	at org.apache.curator.CuratorZookeeperClient.getZooKeeper(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(
> 	at org.apache.curator.framework.imps.CreateBuilderImpl.pathInBackground(
> 	at org.apache.curator.framework.imps.CreateBuilderImpl.forPath(
> 	at org.apache.curator.framework.imps.CreateBuilderImpl.forPath(
> 	at
> 	at$000(
> 	at$4.processResult(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.sendToBackgroundCallback(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.checkBackgroundRetry(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(
> 	at org.apache.curator.framework.imps.CreateBuilderImpl.sendBackgroundResponse(
> 	at org.apache.curator.framework.imps.CreateBuilderImpl.access$600(
> 	at org.apache.curator.framework.imps.CreateBuilderImpl$6.processResult(
> 	at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(
> 	at org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(
> 	- locked <0x00000000fa8e16f8> (a java.util.concurrent.LinkedBlockingQueue)
> 	at org.apache.zookeeper.ClientCnxn.finishPacket(
> 	at org.apache.zookeeper.ClientCnxn.conLossPacket(
> 	at org.apache.zookeeper.ClientCnxn.access$2400(
> 	at org.apache.zookeeper.ClientCnxn$SendThread.cleanup(
> 	- locked <0x00000000fa8e1380> (a java.util.LinkedList)
> 	at org.apache.zookeeper.ClientCnxn$
> "CuratorFramework-0" daemon prio=10 tid=0x00007fd02cb57800 nid=0x4425 in Object.wait()
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(
> 	at org.apache.zookeeper.ClientCnxn.submitRequest(
> 	- locked <0x00000000fa8e6750> (a org.apache.zookeeper.ClientCnxn$Packet)
> 	at org.apache.zookeeper.ClientCnxn.close(
> 	at org.apache.zookeeper.ZooKeeper.close(
> 	- locked <0x00000000fa8e0948> (a org.apache.zookeeper.ZooKeeper)
> 	at org.apache.curator.HandleHolder.internalClose(
> 	at org.apache.curator.HandleHolder.closeAndReset(
> 	at org.apache.curator.ConnectionState.reset(
> 	- locked <0x00000000d526bcc8> (a org.apache.curator.ConnectionState)
> 	at org.apache.curator.ConnectionState.checkTimeouts(
> 	- locked <0x00000000d526bcc8> (a org.apache.curator.ConnectionState)
> 	at org.apache.curator.ConnectionState.getZooKeeper(
> 	at org.apache.curator.CuratorZookeeperClient.getZooKeeper(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(
> 	at org.apache.curator.framework.imps.CuratorFrameworkImpl$
> 	at java.util.concurrent.FutureTask$Sync.innerRun(
> 	at
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at
> Help me Obi-Wan Kenobi, you're my only hope. 

This message was sent by Atlassian JIRA

View raw message