ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Avoid closing caches on client during cluster restart - determining it's the same cache
Date Wed, 11 Oct 2017 23:07:27 GMT
Hello Ilya,

Isn’t the cache name itself sufficient to make all the validations? The cache name is a
unique parameter.

Furthermore, we do not check CacheConfiguration settings provided by the client if CacheConfiguration.name
is already deployed when the client tries to get a reference to the cache (Ignite.getOrCreateCache(cacheCfg)).
Don’t think we should make any exception for the restart scenarios.

—
Denis
 
 
> On Oct 11, 2017, at 5:20 AM, Ilya Kasnacheev <ilya.kasnacheev@gmail.com> wrote:
> 
> Hello Igniters!
> 
> I'm working on IGNITE-2766. We want caches opened on client to survive
> cluster restart (all nodes down, then some nodes up). Currently Ignite
> compares deploymentId which will not match with new cluster's caches.
> 
> But still we want to make sure it's still the same cache in the new
> cluster, and not a different one with the same name. One obvious idea is to
> look at CacheConfiguration. However I think a frequent scenario for cluster
> restart is a minor change of cache configuration (e.g. add or remove
> backup), and it will be a pity to lose client caches in this case.
> 
> So, what fields in CacheConfiguration should we compare upon to figure out
> if it's still the same cache? Name obviously. How does grpName work and
> should we compare on them too?
> 
> indexedTypes[] make sense because if it's a cache on different types it's
> not safe to be used where it was open. cache mode and atomicity mode make
> sence since cache should now be handled differently?
> 
> Any other fields in CacheConfiguration we should check because it's not
> safe to continue in case of mismatch? Some different approach? Suggestions
> are kindly welcome
> 
> -- 
> Ilya Kasnacheev


Mime
View raw message