How are you verifying that there is no ephemeral node? -Jordan
On 2/6/12 9:28 AM, "Hartmut Lang" <[email protected]> wrote: >Hi Jordan, > >thanks for your infos. >What i see in my LeaderSelector example is this: >when i just call the start() method after RECONNECT, the takeLeadership() >method is called again. >But no ephemeral node does exist in the ZK-Cluster for my client. So this >seems not to be right. >What could i do wrong? > >/Hartmut >Am 6. Februar 2012 07:55 schrieb Jordan Zimmerman ><[email protected]>: > >> No - don't call close. I'm afraid that it's a bit confusing. It was an >> afterthought. Maybe I should add a restart() method or something. >> >> -JZ >> >> On 2/5/12 10:48 PM, "Hartmut Lang" <[email protected]> wrote: >> >> >Thanks for your answer. >> >If i call start() again on the same instance, should i call close() >> >before? >> > >> >My first attempt was to call close() on the LeaderSelector on a >> >LOST-Event. >> >Well then of course i do not get again the RECONNECT event on the >> >LeaderSelectorListener. >> > >> >/Hartmut >> > >> >Am 5. Februar 2012 23:53 schrieb Jordan Zimmerman >> ><[email protected]>: >> > >> >> You can either create a new LeaderSelector or call start() again on >>your >> >> existing leader instance. Whatever's easier for your use-case. >> >> >> >> -Jordan >> >> >> >> On 2/5/12 8:09 AM, "Hartmut Lang" <[email protected]> >>wrote: >> >> >> >> >Hi, >> >> > >> >> >i work on a small demo application using the Curator >>Leader-Election. >> >> >What i understand from the wiki is that on a connection LOST-event, >>the >> >> >leader should end his takeLeadership method. >> >> > >> >> >But what should be done with the LeaderSelector instance? >> >> >Should this be also closed on a LOST-event? Or can it be re-used, >>when >> >> >RECONNECTED occurs? >> >> >How can the LeaderSelector be restarted on RECONNECTED? >> >> > >> >> >Hope someone can help, >> >> >Hartmut >> >> >> >> >> >>
