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 < [email protected]> 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 <[email protected]> > *à :* [email protected], Bruno Freudensprung < > [email protected]> > *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 < > [email protected]> 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 <[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 > > On Sun, Nov 1, 2020 at 11:11 AM Bruno Freudensprung < > [email protected]> 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. > >
