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 > >> > >> > >
