Re: Curator PersistentNode recipe

2020-10-04 Thread evaristo.camar...@yahoo.es
 Thx a lot Jordan
En domingo, 4 de octubre de 2020 18:29:43 CEST, Jordan Zimmerman 
 escribió:  
 
 Yes - the node is deleted ala:
client.delete().guaranteed().forPath(localNodePath);
So, if the connection is currently lost the path is added to an internal queue 
and deleted when the connection is repaired.
-Jordan


On Oct 3, 2020, at 12:17 PM, evaristo.camar...@yahoo.es wrote:
Hi there,
I am using Curator's 4.3.0 PersistentNode recipe to keep an ephemeral node 
against a ZK cluster.
In some circumstances I need to close the PersistentNode instance using close() 
method when the connection to the ZK cluster could be LOST. In that scenario, 
the close() method is throwing an IOException that is wrapping a 
ConnectionLossException and basically removeWatches() call is not done...
Checking the code, my understanding is that once connection with the cluster 
happens again, watches are removed and node is deleted (even when the recipe 
was closed)...
I would appreciate if someone could confirm that my assumption is correct and 
that is the expected behaviour of the recipe

Thanks in advance,
/Evaristo


  

Re: Curator PersistentNode recipe

2020-10-04 Thread Jordan Zimmerman
Yes - the node is deleted ala:

client.delete().guaranteed().forPath(localNodePath);

So, if the connection is currently lost the path is added to an internal queue 
and deleted when the connection is repaired.

-Jordan

> On Oct 3, 2020, at 12:17 PM, evaristo.camar...@yahoo.es wrote:
> 
> Hi there,
> 
> I am using Curator's 4.3.0 PersistentNode recipe to keep an ephemeral node 
> against a ZK cluster.
> 
> In some circumstances I need to close the PersistentNode instance using 
> close() method when the connection to the ZK cluster could be LOST. In that 
> scenario, the close() method is throwing an IOException that is wrapping a 
> ConnectionLossException and basically removeWatches() call is not done...
> 
> Checking the code, my understanding is that once connection with the cluster 
> happens again, watches are removed and node is deleted (even when the recipe 
> was closed)...
> 
> I would appreciate if someone could confirm that my assumption is correct and 
> that is the expected behaviour of the recipe
> 
> 
> Thanks in advance,
> 
> /Evaristo
>