cache recipes
Hi, I'm trying to use a cache recipe, like the TreeCache. The cache itself works just fine but what I don't understand is how I'm supposed to handle locally triggered updates correctly. I can start the TreeCache and using the events I know when it is initialized but what if I delete a child node or update a node for example? If I read the data out of the cache before I get the corresponding update events I get old data. As there doesn't seem to be an invalidation mechanism I seem to be required to track outstanding updates. Or am I missing something? regards, Hendrik
Re: cache recipes
Thanks, that was a pretty fast answer! Not quite what I had hoped for but at least now I know that I was right that I have to handle this myself :-) On 17.11.2016 21:13, Cameron McKenzie wrote: Hey Hendrick, The recipes don't treat local updates any differently to remote updates. The cache will get updated when the cursor client receives a watch event from Zookeeper. So your assertions are correct. The caches provide eventual consistency. If you need to ensure that there are no dirty reads between when you write locally and when you read from the cache you would need to wrap the cache in some manner. Cheers On 18 Nov 2016 7:06 AM, "Hendrik Haddorp" <mailto:hendrik.hadd...@gmx.net>> wrote: Hi, I'm trying to use a cache recipe, like the TreeCache. The cache itself works just fine but what I don't understand is how I'm supposed to handle locally triggered updates correctly. I can start the TreeCache and using the events I know when it is initialized but what if I delete a child node or update a node for example? If I read the data out of the cache before I get the corresponding update events I get old data. As there doesn't seem to be an invalidation mechanism I seem to be required to track outstanding updates. Or am I missing something? regards, Hendrik
org.apache.curator.x.async.modeled.details.ModeledFrameworkImpl.delete(int)
Hi,
org.apache.curator.x.async.modeled.details.ModeledFrameworkImpl.delete(int)
is defined as:
public AsyncStage delete(int version)
{
return
dslClient.delete().withVersion(-1).forPath(modelSpec.path().fullPath());
}
Shouldn't the -1 be "version"?
regards,
Hendrik
org.apache.curator.x.async.modeled.details.CachedModeledFrameworkImpl.children()
Hi, org.apache.curator.x.async.modeled.details.CachedModeledFrameworkImpl.children() and org.apache.curator.x.async.modeled.details.CachedModeledFrameworkImpl.childrenAsZNodes() do not seem to work. This filter condition looks wrong to me: .filter(path -> path.equals(cache.basePath())) Getting the children on an uncached model works just fine but on a cached model I always get an empty list. The list that cache.currentChildren(client.modelSpec().path()) returns within the methods looks correct but then there is this strange additional path filtering that throws away everything. This seems to be the test code for that class. I don't fully understand the tests but it looks like the children calls are not tested. Shall I open a defect or is this enough? regards, Hendrik
typed model with multiple classes
Hi,
is it possible to create a typed model that contains hierarchical
objects of different types? For example if I have user and group objects
and want to store them like this:
/groups/{groupId}/users/{userId}
Using TypedModeledFramework I could set a type for the parameters in the
ZPath but the objects returned from the model are always the same. I
would like to get Group objects on the group level and User objects on
the user level. The objects should only contain data from their level.
I got this working by having two typed models and then only load data on
the correct position. This is however a bit error prone and if I would
use a cached model I would end up having all nodes in both caches. Thus
I would be interested in a better solution.
thanks,
Hendrik
Re: org.apache.curator.x.async.modeled.details.CachedModeledFrameworkImpl.children()
I opened CURATOR-479 now: https://issues.apache.org/jira/browse/CURATOR-479 On 07.09.2018 19:59, Jordan Zimmerman wrote: Wow - I think this is a bug. If you don't mind, please open an issue in Curator's Jira On Sep 7, 2018, at 8:02 AM, Hendrik Haddorp wrote: Hi, org.apache.curator.x.async.modeled.details.CachedModeledFrameworkImpl.children() and org.apache.curator.x.async.modeled.details.CachedModeledFrameworkImpl.childrenAsZNodes() do not seem to work. This filter condition looks wrong to me: .filter(path -> path.equals(cache.basePath())) Getting the children on an uncached model works just fine but on a cached model I always get an empty list. The list that cache.currentChildren(client.modelSpec().path()) returns within the methods looks correct but then there is this strange additional path filtering that throws away everything. This seems to be the test code for that class. I don't fully understand the tests but it looks like the children calls are not tested. Shall I open a defect or is this enough? regards, Hendrik
Re: org.apache.curator.x.async.modeled.details.ModeledFrameworkImpl.delete(int)
I opened CURATOR-480 for this:
https://issues.apache.org/jira/browse/CURATOR-480
On 07.09.2018 13:08, Hendrik Haddorp wrote:
org.apache.curator.x.async.modeled.details.ModeledFrameworkImpl.delete(int)
is defined as:
public AsyncStage delete(int version)
{
return
dslClient.delete().withVersion(-1).forPath(modelSpec.path().fullPath());
}
Shouldn't the -1 be "version"?
