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 <[email protected]>
à : [email protected], Bruno Freudensprung <[email protected]>
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
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.
