Mailing-List: contact user-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@curator.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
References: 
 <CAKfdukdueF_E2--YwRpBM7=RSUcwWTgFE=bJ6HS7yqhcR7iXtw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: 
 <CAKfdukdueF_E2--YwRpBM7=RSUcwWTgFE=bJ6HS7yqhcR7iXtw@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F489BAD-D11A-42F0-B04E-264AEBF1B5B4@jordanzimmerman.com>
Cc: "user@curator.apache.org" <user@curator.apache.org>
From: Jordan Zimmerman <jordan@jordanzimmerman.com>
Subject: Re: Curator Framework Close() is NOT always shutting down
 ConnectionStateManager threads
Date: Fri, 7 Feb 2014 17:31:12 -0500
To: "user@curator.apache.org" <user@curator.apache.org>

Close is supposed to shutdown everything. What version are you using? Can yo=
u create a test case that exhibits the problem?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jordan Zimmerman

> On Feb 7, 2014, at 4:35 PM, Raji Muthupandian <rajim17@gmail.com> wrote:
>=20
> Hi Team,
>      We have 5 server Zookeeper ensemble. If any one of the server goes do=
wn, connections are balanced to remaining servers. When the down server come=
s back, there will not be any connections to this server unless new clients a=
re connected or connectionLoss happens at client side. This makes a unequal c=
onnection distribution to the servers.
>=20
> To avoid this, we thought of having a connection balancer task which close=
s the existing connection and creates new connection on every configured tim=
e interval. As part of connection close, we call Curatorframework.close().
>         But in some instances , ConnectionStateManager threads are not clo=
sed. Threads are still in WAITING state to take events from eventqueue.=20
>=20
> "ConnectionStateManager-0" - Thread t@272
>    java.lang.Thread.State: WAITING
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for <3be45251> (a java.util.concurrent.locks.Abstrac=
tQueuedSynchronizer$ConditionObject)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObje=
ct.await(AbstractQueuedSynchronizer.java:2043)
>     at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.jav=
a:374)
>     at com.netflix.curator.framework.state.ConnectionStateManager.processE=
vents(ConnectionStateManager.java:170)
>     at com.netflix.curator.framework.state.ConnectionStateManager.access$0=
00(ConnectionStateManager.java:40)
>     at com.netflix.curator.framework.state.ConnectionStateManager$1.call(C=
onnectionStateManager.java:104)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecuto=
r.java:1145)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecut=
or.java:615)
>     at java.lang.Thread.run(Thread.java:724
>=20
> This creates lot of dangling threads over a period of time. Is there a way=
 to cleanly close the connections ?
>=20
> is there any better approach to handle connection balancing....
>=20
> Thanks
> Raji