You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@helix.apache.org by Bruno Freudensprung <br...@orange.fr> on 2020/11/01 19:11:36 UTC
Stopping participants and controllers
Hi,
I am a new user of Apache Helix, I started prototyping and so far I'm excited
about it :).
I have a question related to stopping participants and controllers.
The demo code is the following :
HelixManager manager = HelixManagerFactory.getZKHelixManager(CLUSTER_NAME,
"localhost_7000", InstanceType.PARTICIPANT, ZK_ADDRESS);
try {
StateMachineEngine stateMach = manager.getStateMachineEngine();
MasterSlaveStateModelFactory stateModelFactory = new
MasterSlaveStateModelFactory();
stateMach.registerStateModelFactory(STATE_MODEL_NAME, stateModelFactory);
manager.connect();
System.in.read(); // wait for user input before stopping the participant
} catch (Exception e) {
e.printStackTrace();
} finally {
manager.disconnect();
}
My problem is the program is hanging after manager.disconnect() because some
threads are still alive. They are created here:
1 - First one is created in the constructor of ZKHelixManager that is calling
HelixPropertyFactory.getInstance().getHelixManagerProperty(zkAddress,
clusterName)), that is creating a ConfigAccessor object that is creating a
ZkClient (I don't know how to close it).
2 - Second one is the static SubscribeChangeEventProcessor thread of the
org.apache.helix.manager.zk.CallbackHandler class.
Could you tell me if I forgot something in my program?
I guess I can try to call setDaemon(true) on SubscribeChangeEventProcessor,
but I don't know how I can close the ZkClient.
Thank you!
Bruno.
Re: Stopping participants and controllers
Posted by Hunter Lee <na...@gmail.com>.
Hey Bruno -
>
> I have the impression this (any?) private static thread should be a daemon
> thread: it would not harm and would allow to exit the JVM programmatically.
>
If you could create an issue on Apache Helix GitHub with a little more
context on how you're planning to use Helix and explain why this should be
a daemon thread, that would be great! You could either first create an
issue and make code contributions by way of a GitHub pull request, or
someone else might work on it if they feel that this modification is needed.
Hunter
On Mon, Nov 2, 2020 at 8:49 AM Bruno Freudensprung <
bruno.freudensprung@orange.fr> wrote:
> Indeed! With 0.9.8 and 1.0.2-SNAPSHOT (freshly built from the master
> branch) I can confirm the only remaining thread is
> SubscribeChangeEventProcessor in
> org.apache.helix.manager.zk.CallbackHandler.
>
> I have the impression this (any?) private static thread should be a daemon
> thread: it would not harm and would allow to exit the JVM programmatically.
>
> In any case, thanks a lot for your help!
>
> Bruno.
>
>
> *envoyé :* 2 novembre 2020 à 17:01
> *de :* Hunter Lee <na...@gmail.com>
> *à :* user@helix.apache.org, Bruno Freudensprung <
> bruno.freudensprung@orange.fr>
> *objet :* Re: Stopping participants and controllers
>
> Hi Bruno -
>
> Yes, feel free to start discussions in this channel. We also have the
> guidelines for contributors on our GitHub page:
> https://github.com/apache/helix/wiki
>
> And yes, that is the code snippet I was referring to - the part where
> "dedicatedZkClient" gets closed in the finally block.
>
> It seems that the version 1.0.1 was generated before the commit. There are
> a few critical bugs we've so far identified and fixed after 1.0.1. For the
> time being, could you give 0.9.8 a try and to see if you could reproduce
> the issue.
>
> Thanks,
> Hunter
>
> On Mon, Nov 2, 2020 at 5:13 AM Bruno Freudensprung <
> bruno.freudensprung@orange.fr> wrote:
>
> Hi Hunter,
>
> Thank you for the warm welcome and for the lightning fast reply! :)
>
>
> Concerning my contribution, for the moment and don't have much but little
> details about source code mentioned in the online documentation.
>
> If you are interested, I would be glad to share though. Just tell me how
> (in this mailing list? elsewhere?).
>
>
> Concerning my problem and your answer, I must admit I am puzzled. Either I
> totally fail at seeing something obvious, or there is something weird.
>
> I have the impression you are referring to the HelixPropertyFactory class
> right ? ("Use a try-finally to make sure zkclient connection is closed
> properly"):
>
>
> https://git-wip-us.apache.org/repos/asf?p=helix.git;a=blob;f=helix-core/src/main/java/org/apache/helix/HelixPropertyFactory.java;h=fa01d7932535c67c9ac9ed3f881ef7c0c0fed853;hb=HEAD
>
> However when I download the source code:
>
> wget
> https://repo.maven.apache.org/maven2/org/apache/helix/helix-core/1.0.1/helix-core-1.0.1-sources.jar
>
> The HelixPropertyFactory seems to be quite different there: it does not
> seem to include your "Thu Jun 25 17:07:10 2020" commit.
>
> IntelliJ decompiler seems to show a decompiled class that is similar to
> the one of the sources jar (build.gradle: implementation group:
> 'org.apache.helix', name: 'helix-core', version: '1.0.1').
>
> Bruno.
>
>
>
> *envoyé :* 1 novembre 2020 à 21:39
> *de :* Hunter Lee <na...@gmail.com>
> *à :* user@helix.apache.org, Bruno Freudensprung <
> bruno.freudensprung@orange.fr>
> *objet :* Re: Stopping participants and controllers
>
> Hey Bruno -
>
> First off, welcome to the Helix community! We're excited to have you use
> it and we welcome any feedback or contribution you'd like to make.
>
> 1. The underlying ZK connection for the ConfigAccessor object actually
> does get closed. See the following:
>
> finally {
> // Use a try-finally to make sure zkclient connection is closed
> properly
> if (dedicatedZkClient != null && !dedicatedZkClient.isClosed()) {
> *dedicatedZkClient.close(); // this has the same effect of
> closing ConfigAccessor*
> }
> }
>
> 2. We do not explicitly close the event processor since almost all use
> cases of manager.disconnect(), which disconnects the participant, assume
> that the lifecycle of the deployable ends with the disconnect, and
> therefore, the JVM itself will be shut down.
>
> All in all though, I don't at quick glance see why your
> manager.disconnect() should hang. Can you try to put a debugger and see
> what stage of disconnect() call it's hanging?
>
> Hunter
>
> On Sun, Nov 1, 2020 at 11:11 AM Bruno Freudensprung <
> bruno.freudensprung@orange.fr> wrote:
>
>
> Hi,
>
> I am a new user of Apache Helix, I started prototyping and so far I'm
> excited about it :).
>
> I have a question related to stopping participants and controllers.
>
> The demo code is the following :
>
> HelixManager manager = HelixManagerFactory.getZKHelixManager(CLUSTER_NAME,
> "localhost_7000", InstanceType.PARTICIPANT, ZK_ADDRESS);
> try {
> StateMachineEngine stateMach = manager.getStateMachineEngine();
> MasterSlaveStateModelFactory stateModelFactory = new
> MasterSlaveStateModelFactory();
> stateMach.registerStateModelFactory(STATE_MODEL_NAME,
> stateModelFactory);
> manager.connect();
> System.in.read(); // wait for user input before stopping the participant
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> manager.disconnect();
> }
>
> My problem is the program is hanging after manager.disconnect() because
> some threads are still alive. They are created here:
>
> 1 - First one is created in the constructor of ZKHelixManager that is
> calling HelixPropertyFactory.getInstance().getHelixManagerProperty(zkAddress,
> clusterName)), that is creating a ConfigAccessor object that is creating
> a ZkClient (I don't know how to close it).
>
> 2 - Second one is the static SubscribeChangeEventProcessor thread of the
> org.apache.helix.manager.zk.CallbackHandler class.
>
> Could you tell me if I forgot something in my program?
> I guess I can try to call setDaemon(true) on SubscribeChangeEventProcessor,
> but I don't know how I can close the ZkClient.
>
> Thank you!
>
> Bruno.
>
>
Re: Stopping participants and controllers
Posted by Bruno Freudensprung <br...@orange.fr>.
Indeed! With 0.9.8 and 1.0.2-SNAPSHOT (freshly built from the master branch) I
can confirm the only remaining thread is SubscribeChangeEventProcessor in
org.apache.helix.manager.zk.CallbackHandler.
I have the impression this (any?) private static thread should be a daemon
thread: it would not harm and would allow to exit the JVM programmatically.
In any case, thanks a lot for your help!
Bruno.
> **envoy e :** 2 novembre 2020 a 17:01
> **de :** Hunter Lee <na...@gmail.com>
> **a :** user@helix.apache.org, Bruno Freudensprung
<br...@orange.fr>
> **objet :** Re: Stopping participants and controllers
>
>
>
>
> Hi Bruno -
>
>
>
>
> Yes, feel free to start discussions in this channel. We also have the
guidelines for contributors on our GitHub page:
<https://github.com/apache/helix/wiki>
>
>
>
>
>
> And yes, that is the code snippet I was referring to - the part where
"dedicatedZkClient" gets closed in the finally block.
>
>
>
>
> It seems that the version 1.0.1 was generated before the commit. There are a
few critical bugs we've so far identified and fixed after 1.0.1. For the time
being, could you give 0.9.8 a try and to see if you could reproduce the issue.
>
>
>
>
> Thanks,
>
> Hunter
>
>
>
>
> On Mon, Nov 2, 2020 at 5:13 AM Bruno Freudensprung
<[bruno.freudensprung@orange.fr](mailto:bruno.freudensprung@orange.fr)> wrote:
>
>
>> __
>>
>> Hi Hunter,
>
>>
>> Thank you for the warm welcome and for the lightning fast reply! :)
>
>>
>>
>
>>
>> Concerning my contribution, for the moment and don't have much but little
details about source code mentioned in the online documentation.
>>
>> If you are interested, I would be glad to share though. Just tell me how
(in this mailing list? elsewhere?).
>
>>
>>
>
>>
>> Concerning my problem and your answer, I must admit I am puzzled. Either I
totally fail at seeing something obvious, or there is something weird.
>
>>
>> I have the impression you are referring to the HelixPropertyFactory class
right ? ("Use a try-finally to make sure zkclient connection is closed
properly"):
>
>>
>> <https://git-wip-us.apache.org/repos/asf?p=helix.git;a=blob;f=helix-
core/src/main/java/org/apache/helix/HelixPropertyFactory.java;h=fa01d7932535c67c9ac9ed3f881ef7c0c0fed853;hb=HEAD>
>
>>
>> However when I download the source code:
>
>>
>> wget <https://repo.maven.apache.org/maven2/org/apache/helix/helix-
core/1.0.1/helix-core-1.0.1-sources.jar>
>
>>
>> The HelixPropertyFactory seems to be quite different there: it does not
seem to include your "Thu Jun 25 17:07:10 2020" commit.
>>
>> IntelliJ decompiler seems to show a decompiled class that is similar to the
one of the sources jar (build.gradle: implementation group:
'org.apache.helix', name: 'helix-core', version: '1.0.1').
>
>>
>> Bruno.
>
>>
>>
>
>>
>>
>
>>
>>> **envoy e :** 1 novembre 2020 a 21:39
> **de :** Hunter Lee <[narendly@gmail.com](mailto:narendly@gmail.com)>
> **a :** [user@helix.apache.org](mailto:user@helix.apache.org), Bruno
Freudensprung
<[bruno.freudensprung@orange.fr](mailto:bruno.freudensprung@orange.fr)>
> **objet :** Re: Stopping participants and controllers
>>>
>>>
>
>>>
>>> Hey Bruno -
>>>
>>>
>
>>>
>>> First off, welcome to the Helix community! We're excited to have you use
it and we welcome any feedback or contribution you'd like to make.
>>>
>>>
>
>>>
>>> 1\. The underlying ZK connection for the ConfigAccessor object actually
does get closed. See the following:
>>>
>>>
>
>>>
>>> finally {
> // Use a try-finally to make sure zkclient connection is closed properly
> if (dedicatedZkClient != null && !dedicatedZkClient.isClosed()) {
> **_dedicatedZkClient.close(); // this has the same effect of closing
ConfigAccessor_**
> }
> }
>
>>>
>>>
>
>>>
>>> 2\. We do not explicitly close the event processor since almost all use
cases of manager.disconnect(), which disconnects the participant, assume that
the lifecycle of the deployable ends with the disconnect, and therefore, the
JVM itself will be shut down.
>>>
>>>
>
>>>
>>> All in all though, I don't at quick glance see why your
manager.disconnect() should hang. Can you try to put a debugger and see what
stage of disconnect() call it's hanging?
>>>
>>>
>
>>>
>>> Hunter
>>>
>>>
>
>>>
>>> On Sun, Nov 1, 2020 at 11:11 AM Bruno Freudensprung
<[bruno.freudensprung@orange.fr](mailto:bruno.freudensprung@orange.fr)> wrote:
>
>>>
>>>> __
>>>>
>>>>
>
>>>>
>>>> Hi,
>
>>>>
>>>> I am a new user of Apache Helix, I started prototyping and so far I'm
excited about it :).
>
>>>>
>>>> I have a question related to stopping participants and controllers.
>
>>>>
>>>> The demo code is the following :
>
>>>>
>>>> HelixManager manager =
HelixManagerFactory.getZKHelixManager(CLUSTER_NAME, "localhost_7000",
InstanceType.PARTICIPANT, ZK_ADDRESS);
> try {
> StateMachineEngine stateMach = manager.getStateMachineEngine();
> MasterSlaveStateModelFactory stateModelFactory = new
MasterSlaveStateModelFactory();
> stateMach.registerStateModelFactory(STATE_MODEL_NAME, stateModelFactory);
> manager.connect();
> System.in.read(); // wait for user input before stopping the participant
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> manager.disconnect();
> }
>>>>
>>>> My problem is the program is hanging after manager.disconnect() because
some threads are still alive. They are created here:
>
>>>>
>>>> 1 - First one is created in the constructor of ZKHelixManager that is
calling HelixPropertyFactory.getInstance().getHelixManagerProperty(zkAddress,
clusterName)), that is creating a ConfigAccessor object that is creating a
ZkClient (I don't know how to close it).
>
>>>>
>>>> 2 - Second one is the static SubscribeChangeEventProcessor thread of the
org.apache.helix.manager.zk.CallbackHandler class.
>
>>>>
>>>> Could you tell me if I forgot something in my program?
> I guess I can try to call setDaemon(true) on SubscribeChangeEventProcessor,
but I don't know how I can close the ZkClient.
>
>>>>
>>>> Thank you!
>
>>>>
>>>> Bruno.
>
Re: Stopping participants and controllers
Posted by Hunter Lee <na...@gmail.com>.
Hi Bruno -
Yes, feel free to start discussions in this channel. We also have the
guidelines for contributors on our GitHub page:
https://github.com/apache/helix/wiki
And yes, that is the code snippet I was referring to - the part where
"dedicatedZkClient" gets closed in the finally block.
It seems that the version 1.0.1 was generated before the commit. There are
a few critical bugs we've so far identified and fixed after 1.0.1. For the
time being, could you give 0.9.8 a try and to see if you could reproduce
the issue.
Thanks,
Hunter
On Mon, Nov 2, 2020 at 5:13 AM Bruno Freudensprung <
bruno.freudensprung@orange.fr> wrote:
> Hi Hunter,
>
> Thank you for the warm welcome and for the lightning fast reply! :)
>
>
> Concerning my contribution, for the moment and don't have much but little
> details about source code mentioned in the online documentation.
>
> If you are interested, I would be glad to share though. Just tell me how
> (in this mailing list? elsewhere?).
>
>
> Concerning my problem and your answer, I must admit I am puzzled. Either I
> totally fail at seeing something obvious, or there is something weird.
>
> I have the impression you are referring to the HelixPropertyFactory class
> right ? ("Use a try-finally to make sure zkclient connection is closed
> properly"):
>
>
> https://git-wip-us.apache.org/repos/asf?p=helix.git;a=blob;f=helix-core/src/main/java/org/apache/helix/HelixPropertyFactory.java;h=fa01d7932535c67c9ac9ed3f881ef7c0c0fed853;hb=HEAD
>
> However when I download the source code:
>
> wget
> https://repo.maven.apache.org/maven2/org/apache/helix/helix-core/1.0.1/helix-core-1.0.1-sources.jar
>
> The HelixPropertyFactory seems to be quite different there: it does not
> seem to include your "Thu Jun 25 17:07:10 2020" commit.
>
> IntelliJ decompiler seems to show a decompiled class that is similar to
> the one of the sources jar (build.gradle: implementation group:
> 'org.apache.helix', name: 'helix-core', version: '1.0.1').
>
> Bruno.
>
>
>
> *envoyé :* 1 novembre 2020 à 21:39
> *de :* Hunter Lee <na...@gmail.com>
> *à :* user@helix.apache.org, Bruno Freudensprung <
> bruno.freudensprung@orange.fr>
> *objet :* Re: Stopping participants and controllers
>
> Hey Bruno -
>
> First off, welcome to the Helix community! We're excited to have you use
> it and we welcome any feedback or contribution you'd like to make.
>
> 1. The underlying ZK connection for the ConfigAccessor object actually
> does get closed. See the following:
>
> finally {
> // Use a try-finally to make sure zkclient connection is closed
> properly
> if (dedicatedZkClient != null && !dedicatedZkClient.isClosed()) {
> *dedicatedZkClient.close(); // this has the same effect of
> closing ConfigAccessor*
> }
> }
>
> 2. We do not explicitly close the event processor since almost all use
> cases of manager.disconnect(), which disconnects the participant, assume
> that the lifecycle of the deployable ends with the disconnect, and
> therefore, the JVM itself will be shut down.
>
> All in all though, I don't at quick glance see why your
> manager.disconnect() should hang. Can you try to put a debugger and see
> what stage of disconnect() call it's hanging?
>
> Hunter
>
> On Sun, Nov 1, 2020 at 11:11 AM Bruno Freudensprung <
> bruno.freudensprung@orange.fr> wrote:
>
>
> Hi,
>
> I am a new user of Apache Helix, I started prototyping and so far I'm
> excited about it :).
>
> I have a question related to stopping participants and controllers.
>
> The demo code is the following :
>
> HelixManager manager = HelixManagerFactory.getZKHelixManager(CLUSTER_NAME,
> "localhost_7000", InstanceType.PARTICIPANT, ZK_ADDRESS);
> try {
> StateMachineEngine stateMach = manager.getStateMachineEngine();
> MasterSlaveStateModelFactory stateModelFactory = new
> MasterSlaveStateModelFactory();
> stateMach.registerStateModelFactory(STATE_MODEL_NAME,
> stateModelFactory);
> manager.connect();
> System.in.read(); // wait for user input before stopping the participant
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> manager.disconnect();
> }
>
> My problem is the program is hanging after manager.disconnect() because
> some threads are still alive. They are created here:
>
> 1 - First one is created in the constructor of ZKHelixManager that is
> calling HelixPropertyFactory.getInstance().getHelixManagerProperty(zkAddress,
> clusterName)), that is creating a ConfigAccessor object that is creating
> a ZkClient (I don't know how to close it).
>
> 2 - Second one is the static SubscribeChangeEventProcessor thread of the
> org.apache.helix.manager.zk.CallbackHandler class.
>
> Could you tell me if I forgot something in my program?
> I guess I can try to call setDaemon(true) on SubscribeChangeEventProcessor,
> but I don't know how I can close the ZkClient.
>
> Thank you!
>
> Bruno.
>
>
Re: Stopping participants and controllers
Posted by Bruno Freudensprung <br...@orange.fr>.
Hi Hunter,
Thank you for the warm welcome and for the lightning fast reply! :)
Concerning my contribution, for the moment and don't have much but little
details about source code mentioned in the online documentation.
If you are interested, I would be glad to share though. Just tell me how (in
this mailing list? elsewhere?).
Concerning my problem and your answer, I must admit I am puzzled. Either I
totally fail at seeing something obvious, or there is something weird.
I have the impression you are referring to the HelixPropertyFactory class
right ? ("Use a try-finally to make sure zkclient connection is closed
properly"):
<https://git-wip-us.apache.org/repos/asf?p=helix.git;a=blob;f=helix-
core/src/main/java/org/apache/helix/HelixPropertyFactory.java;h=fa01d7932535c67c9ac9ed3f881ef7c0c0fed853;hb=HEAD>
However when I download the source code:
wget <https://repo.maven.apache.org/maven2/org/apache/helix/helix-
core/1.0.1/helix-core-1.0.1-sources.jar>
The HelixPropertyFactory seems to be quite different there: it does not seem
to include your "Thu Jun 25 17:07:10 2020" commit.
IntelliJ decompiler seems to show a decompiled class that is similar to the
one of the sources jar (build.gradle: implementation group:
'org.apache.helix', name: 'helix-core', version: '1.0.1').
Bruno.
> **envoy e :** 1 novembre 2020 a 21:39
> **de :** Hunter Lee <na...@gmail.com>
> **a :** user@helix.apache.org, Bruno Freudensprung
<br...@orange.fr>
> **objet :** Re: Stopping participants and controllers
>
>
>
>
> Hey Bruno -
>
>
>
>
> First off, welcome to the Helix community! We're excited to have you use it
and we welcome any feedback or contribution you'd like to make.
>
>
>
>
> 1\. The underlying ZK connection for the ConfigAccessor object actually does
get closed. See the following:
>
>
>
>
> finally {
> // Use a try-finally to make sure zkclient connection is closed properly
> if (dedicatedZkClient != null && !dedicatedZkClient.isClosed()) {
> **_dedicatedZkClient.close(); // this has the same effect of closing
ConfigAccessor_**
> }
> }
>
>
>
>
>
> 2\. We do not explicitly close the event processor since almost all use
cases of manager.disconnect(), which disconnects the participant, assume that
the lifecycle of the deployable ends with the disconnect, and therefore, the
JVM itself will be shut down.
>
>
>
>
> All in all though, I don't at quick glance see why your manager.disconnect()
should hang. Can you try to put a debugger and see what stage of disconnect()
call it's hanging?
>
>
>
>
> Hunter
>
>
>
>
> On Sun, Nov 1, 2020 at 11:11 AM Bruno Freudensprung
<[bruno.freudensprung@orange.fr](mailto:bruno.freudensprung@orange.fr)> wrote:
>
>
>> __
>>
>>
>
>>
>> Hi,
>
>>
>> I am a new user of Apache Helix, I started prototyping and so far I'm
excited about it :).
>
>>
>> I have a question related to stopping participants and controllers.
>
>>
>> The demo code is the following :
>
>>
>> HelixManager manager = HelixManagerFactory.getZKHelixManager(CLUSTER_NAME,
"localhost_7000", InstanceType.PARTICIPANT, ZK_ADDRESS);
> try {
> StateMachineEngine stateMach = manager.getStateMachineEngine();
> MasterSlaveStateModelFactory stateModelFactory = new
MasterSlaveStateModelFactory();
> stateMach.registerStateModelFactory(STATE_MODEL_NAME, stateModelFactory);
> manager.connect();
> System.in.read(); // wait for user input before stopping the participant
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> manager.disconnect();
> }
>>
>> My problem is the program is hanging after manager.disconnect() because
some threads are still alive. They are created here:
>
>>
>> 1 - First one is created in the constructor of ZKHelixManager that is
calling HelixPropertyFactory.getInstance().getHelixManagerProperty(zkAddress,
clusterName)), that is creating a ConfigAccessor object that is creating a
ZkClient (I don't know how to close it).
>
>>
>> 2 - Second one is the static SubscribeChangeEventProcessor thread of the
org.apache.helix.manager.zk.CallbackHandler class.
>
>>
>> Could you tell me if I forgot something in my program?
> I guess I can try to call setDaemon(true) on SubscribeChangeEventProcessor,
but I don't know how I can close the ZkClient.
>
>>
>> Thank you!
>
>>
>> Bruno.
>
Re: Stopping participants and controllers
Posted by Hunter Lee <na...@gmail.com>.
Hey Bruno -
First off, welcome to the Helix community! We're excited to have you use it
and we welcome any feedback or contribution you'd like to make.
1. The underlying ZK connection for the ConfigAccessor object actually does
get closed. See the following:
finally {
// Use a try-finally to make sure zkclient connection is closed
properly
if (dedicatedZkClient != null && !dedicatedZkClient.isClosed()) {
*dedicatedZkClient.close(); // this has the same effect of closing
ConfigAccessor*
}
}
2. We do not explicitly close the event processor since almost all use
cases of manager.disconnect(), which disconnects the participant, assume
that the lifecycle of the deployable ends with the disconnect, and
therefore, the JVM itself will be shut down.
All in all though, I don't at quick glance see why your
manager.disconnect() should hang. Can you try to put a debugger and see
what stage of disconnect() call it's hanging?
Hunter
On Sun, Nov 1, 2020 at 11:11 AM Bruno Freudensprung <
bruno.freudensprung@orange.fr> wrote:
>
> Hi,
>
> I am a new user of Apache Helix, I started prototyping and so far I'm
> excited about it :).
>
> I have a question related to stopping participants and controllers.
>
> The demo code is the following :
>
> HelixManager manager = HelixManagerFactory.getZKHelixManager(CLUSTER_NAME,
> "localhost_7000", InstanceType.PARTICIPANT, ZK_ADDRESS);
> try {
> StateMachineEngine stateMach = manager.getStateMachineEngine();
> MasterSlaveStateModelFactory stateModelFactory = new
> MasterSlaveStateModelFactory();
> stateMach.registerStateModelFactory(STATE_MODEL_NAME,
> stateModelFactory);
> manager.connect();
> System.in.read(); // wait for user input before stopping the participant
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> manager.disconnect();
> }
>
> My problem is the program is hanging after manager.disconnect() because
> some threads are still alive. They are created here:
>
> 1 - First one is created in the constructor of ZKHelixManager that is
> calling HelixPropertyFactory.getInstance().getHelixManagerProperty(zkAddress,
> clusterName)), that is creating a ConfigAccessor object that is creating
> a ZkClient (I don't know how to close it).
>
> 2 - Second one is the static SubscribeChangeEventProcessor thread of the
> org.apache.helix.manager.zk.CallbackHandler class.
>
> Could you tell me if I forgot something in my program?
> I guess I can try to call setDaemon(true) on SubscribeChangeEventProcessor,
> but I don't know how I can close the ZkClient.
>
> Thank you!
>
> Bruno.
>