You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Jordan Zimmerman (JIRA)" <ji...@apache.org> on 2013/09/05 07:21:51 UTC
[jira] [Resolved] (CURATOR-52) Callbacks are not called on
retry-able errors
[ https://issues.apache.org/jira/browse/CURATOR-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jordan Zimmerman resolved CURATOR-52.
-------------------------------------
Resolution: Fixed
Patch applied and merged. Pushed into master.
> Callbacks are not called on retry-able errors
> ---------------------------------------------
>
> Key: CURATOR-52
> URL: https://issues.apache.org/jira/browse/CURATOR-52
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 2.2.0-incubating
> Reporter: Michael Morello
> Assignee: Jordan Zimmerman
> Fix For: TBD
>
> Attachments: CURATOR-52.patch
>
>
> Retry-able errors (CONNECTIONLOSS, OPERATIONTIMEOUT, SESSIONMOVED, SESSIONEXPIRED) are not propagated to callback when the retry policy gave up if the operation is done in background.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: PathChildrenCachebehaviour when reconnected
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
OK - I understand now.
You are correct, if there has been a disconnect event, when you reconnect you have no guarantee for consistency. Consistency will occur eventually. Over the next few minutes after reconnection consistency will be achieved and corresponding ADD/UPDATE/REMOVE messages sent.
-JZ
On Sep 26, 2013, at 8:42 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
> Thanks for the fast answer.
>
> Is the POST_INITIALIZED_EVENT triggered on RECONNECTION? I thought it was only available during the FIRST CONNECTION
>
> Let me repeat what I have understand to be sure it is right
>
> After some period connected, when Curator framework is DISCONNECTED (e.g. network issue), the cache will be non updated (e.g. some changes in the nodes). Once the ZK client RECONNECTS, the cache triggers the RECONNECTED event, BUT I do not have guarantee when the RECONNECTED event is received that cache has finished its sync with ZK. Is that OK?
>
> I assume that after RECONNECTION the cache will be updated and other events (child added, removed, changed) will be triggered. IS that OK?
>
> Thanks in adavance,
>
> Evaristo
>
> De: Jordan Zimmerman <jo...@jordanzimmerman.com>
> Para: dev@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
> CC: "user@curator.incubator.apache.org" <us...@curator.incubator.apache.org>
> Enviado: Jueves 26 de septiembre de 2013 16:54
> Asunto: Re: PathChildrenCachebehaviour when reconnected
>
> > Can I assume that the initial cache sync with ZK has finished when this is received?
> No - this is just a duplicate of the normal Curator connection state event.
>
> > is there anyway to know when the initial sync has finished?
> Start the cache with StartMode.POST_INITIALIZED_EVENT and wait for PathChildrenCacheEvent.Type.INITIALIZED
>
>
>
Re: PathChildrenCachebehaviour when reconnected
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
OK - I understand now.
You are correct, if there has been a disconnect event, when you reconnect you have no guarantee for consistency. Consistency will occur eventually. Over the next few minutes after reconnection consistency will be achieved and corresponding ADD/UPDATE/REMOVE messages sent.
-JZ
On Sep 26, 2013, at 8:42 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
> Thanks for the fast answer.
>
> Is the POST_INITIALIZED_EVENT triggered on RECONNECTION? I thought it was only available during the FIRST CONNECTION
>
> Let me repeat what I have understand to be sure it is right
>
> After some period connected, when Curator framework is DISCONNECTED (e.g. network issue), the cache will be non updated (e.g. some changes in the nodes). Once the ZK client RECONNECTS, the cache triggers the RECONNECTED event, BUT I do not have guarantee when the RECONNECTED event is received that cache has finished its sync with ZK. Is that OK?
>
> I assume that after RECONNECTION the cache will be updated and other events (child added, removed, changed) will be triggered. IS that OK?
>
> Thanks in adavance,
>
> Evaristo
>
> De: Jordan Zimmerman <jo...@jordanzimmerman.com>
> Para: dev@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
> CC: "user@curator.incubator.apache.org" <us...@curator.incubator.apache.org>
> Enviado: Jueves 26 de septiembre de 2013 16:54
> Asunto: Re: PathChildrenCachebehaviour when reconnected
>
> > Can I assume that the initial cache sync with ZK has finished when this is received?
> No - this is just a duplicate of the normal Curator connection state event.
>
> > is there anyway to know when the initial sync has finished?
> Start the cache with StartMode.POST_INITIALIZED_EVENT and wait for PathChildrenCacheEvent.Type.INITIALIZED
>
>
>
Re: PathChildrenCachebehaviour when reconnected
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Thanks for the fast answer.
Is the POST_INITIALIZED_EVENT triggered on RECONNECTION? I thought it was only available during the FIRST CONNECTION
Let me repeat what I have understand to be sure it is right
After some period connected, when Curator framework is DISCONNECTED (e.g. network issue), the cache will be non updated (e.g. some changes in the nodes). Once the ZK client RECONNECTS, the cache triggers the RECONNECTED event, BUT I do not have guarantee when the RECONNECTED event is received that cache has finished its sync with ZK. Is that OK?
I assume that after RECONNECTION the cache will be updated and other events (child added, removed, changed) will be triggered. IS that OK?
Thanks in adavance,
Evaristo
________________________________
De: Jordan Zimmerman <jo...@jordanzimmerman.com>
Para: dev@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
CC: "user@curator.incubator.apache.org" <us...@curator.incubator.apache.org>
Enviado: Jueves 26 de septiembre de 2013 16:54
Asunto: Re: PathChildrenCachebehaviour when reconnected
> Can I assume that the initial cache sync with ZK has finished when this is received?
No - this is just a duplicate of the normal Curator connection state event.
> is there anyway to know when the initial sync has finished?
Start the cache with StartMode.POST_INITIALIZED_EVENT and wait for PathChildrenCacheEvent.Type.INITIALIZED
Re: PathChildrenCachebehaviour when reconnected
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Thanks for the fast answer.
Is the POST_INITIALIZED_EVENT triggered on RECONNECTION? I thought it was only available during the FIRST CONNECTION
Let me repeat what I have understand to be sure it is right
After some period connected, when Curator framework is DISCONNECTED (e.g. network issue), the cache will be non updated (e.g. some changes in the nodes). Once the ZK client RECONNECTS, the cache triggers the RECONNECTED event, BUT I do not have guarantee when the RECONNECTED event is received that cache has finished its sync with ZK. Is that OK?
I assume that after RECONNECTION the cache will be updated and other events (child added, removed, changed) will be triggered. IS that OK?
Thanks in adavance,
Evaristo
________________________________
De: Jordan Zimmerman <jo...@jordanzimmerman.com>
Para: dev@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
CC: "user@curator.incubator.apache.org" <us...@curator.incubator.apache.org>
Enviado: Jueves 26 de septiembre de 2013 16:54
Asunto: Re: PathChildrenCachebehaviour when reconnected
> Can I assume that the initial cache sync with ZK has finished when this is received?
No - this is just a duplicate of the normal Curator connection state event.
> is there anyway to know when the initial sync has finished?
Start the cache with StartMode.POST_INITIALIZED_EVENT and wait for PathChildrenCacheEvent.Type.INITIALIZED
Re: PathChildrenCachebehaviour when reconnected
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
> Can I assume that the initial cache sync with ZK has finished when this is received?
No - this is just a duplicate of the normal Curator connection state event.
> is there anyway to know when the initial sync has finished?
Start the cache with StartMode.POST_INITIALIZED_EVENT and wait for PathChildrenCacheEvent.Type.INITIALIZED
Re: PathChildrenCachebehaviour when reconnected
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
> Can I assume that the initial cache sync with ZK has finished when this is received?
No - this is just a duplicate of the normal Curator connection state event.
> is there anyway to know when the initial sync has finished?
Start the cache with StartMode.POST_INITIALIZED_EVENT and wait for PathChildrenCacheEvent.Type.INITIALIZED
PathChildrenCachebehaviour when reconnected
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
I am using PathChildrenCache recipe and PathChildrenCacheListener to receive cache relevant events.
My doubt is when a PathChildrenCacheEvent.Type.CONNECTION_RECONNECTED is received. Can I assume that the initial cache sync with ZK has finished when this is received? If that is not the case, is there anyway to know when the initial sync has finished?
Thanks in advance,
Evaristo
Re: PersistentEphemeralNode possible bug
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Yes, that would definitely be a bug. Please open an issue (with a complete test if possible) at https://issues.apache.org/jira/browse/CURATOR
On Sep 5, 2013, at 8:14 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>
>
> Hi there,
>
> I am using the PersistentEphemeralNode, and I have noticed that it is needed to make it work assure that the PersistentEphemeralNode instance started when the CuratorFramework is connected. Otherwise it looks that the recipee does not work
>
> For instance this sequence is not working:
>
> // ZK servers are not started here
> ExponentialBackoffRetry retryPolicy = new ExponentialBackoffRetry(1000, 1, 2000);
> CuratorFramework zkClient = CuratorFrameworkFactory.newClient("127.0.0.1:30101",
>
> 4500,
> 4500,
> retryPolicy);
> zkClient.start();
> Thread.sleep(2000);
>
> PersistentEphemeralNode pen = new PersistentEphemeralNode(zkClient, Mode.EPHEMERAL, "/abc/pen", "hello".getBytes());
> Thread.sleep(2000);
>
> // Start ZK servers here
> Thread.sleep(2000);
> // "/abc/pen" ephemeral node is not created
>
> Is this a bug? Is it assumed that a connection listener should be used to start the PersistentEphemeralNode when the zkclient is connected?
>
>
> Thanks in advance,
>
> Evaristo
PathChildrenCachebehaviour when reconnected
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
I am using PathChildrenCache recipe and PathChildrenCacheListener to receive cache relevant events.
My doubt is when a PathChildrenCacheEvent.Type.CONNECTION_RECONNECTED is received. Can I assume that the initial cache sync with ZK has finished when this is received? If that is not the case, is there anyway to know when the initial sync has finished?
Thanks in advance,
Evaristo
Re: PersistentEphemeralNode possible bug
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Yes, that would definitely be a bug. Please open an issue (with a complete test if possible) at https://issues.apache.org/jira/browse/CURATOR
On Sep 5, 2013, at 8:14 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>
>
> Hi there,
>
> I am using the PersistentEphemeralNode, and I have noticed that it is needed to make it work assure that the PersistentEphemeralNode instance started when the CuratorFramework is connected. Otherwise it looks that the recipee does not work
>
> For instance this sequence is not working:
>
> // ZK servers are not started here
> ExponentialBackoffRetry retryPolicy = new ExponentialBackoffRetry(1000, 1, 2000);
> CuratorFramework zkClient = CuratorFrameworkFactory.newClient("127.0.0.1:30101",
>
> 4500,
> 4500,
> retryPolicy);
> zkClient.start();
> Thread.sleep(2000);
>
> PersistentEphemeralNode pen = new PersistentEphemeralNode(zkClient, Mode.EPHEMERAL, "/abc/pen", "hello".getBytes());
> Thread.sleep(2000);
>
> // Start ZK servers here
> Thread.sleep(2000);
> // "/abc/pen" ephemeral node is not created
>
> Is this a bug? Is it assumed that a connection listener should be used to start the PersistentEphemeralNode when the zkclient is connected?
>
>
> Thanks in advance,
>
> Evaristo
PersistentEphemeralNode possible bug
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
I am using the PersistentEphemeralNode, and I have noticed that it is needed to make it work assure that the PersistentEphemeralNode instance started when the CuratorFramework is connected. Otherwise it looks that the recipee does not work
For instance this sequence is not working:
// ZK servers are not started here
ExponentialBackoffRetry retryPolicy = new ExponentialBackoffRetry(1000, 1, 2000);
CuratorFramework zkClient = CuratorFrameworkFactory.newClient("127.0.0.1:30101",
4500,
4500,
retryPolicy);
zkClient.start();
Thread.sleep(2000);
PersistentEphemeralNode pen = new PersistentEphemeralNode(zkClient, Mode.EPHEMERAL, "/abc/pen", "hello".getBytes());
Thread.sleep(2000);
// Start ZK servers here
Thread.sleep(2000);
// "/abc/pen" ephemeral node is not created
Is this a bug? Is it assumed that a connection listener should be used to start the PersistentEphemeralNode when the zkclient is connected?
Thanks in advance,
Evaristo
PersistentEphemeralNode possible bug
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
I am using the PersistentEphemeralNode, and I have noticed that it is needed to make it work assure that the PersistentEphemeralNode instance started when the CuratorFramework is connected. Otherwise it looks that the recipee does not work
For instance this sequence is not working:
// ZK servers are not started here
ExponentialBackoffRetry retryPolicy = new ExponentialBackoffRetry(1000, 1, 2000);
CuratorFramework zkClient = CuratorFrameworkFactory.newClient("127.0.0.1:30101",
4500,
4500,
retryPolicy);
zkClient.start();
Thread.sleep(2000);
PersistentEphemeralNode pen = new PersistentEphemeralNode(zkClient, Mode.EPHEMERAL, "/abc/pen", "hello".getBytes());
Thread.sleep(2000);
// Start ZK servers here
Thread.sleep(2000);
// "/abc/pen" ephemeral node is not created
Is this a bug? Is it assumed that a connection listener should be used to start the PersistentEphemeralNode when the zkclient is connected?
Thanks in advance,
Evaristo