Hello Ilya, > > Or do you mean that we ignore cfg in getOrCreateCaches() if name is matched > to already existing cache?
Yes, this is what I grasped from the source code. — Denis > On Oct 16, 2017, at 2:29 AM, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > wrote: > > Hello Denis! > >> we do not check CacheConfiguration settings provided by the client > > Are you sure about that? I've just tried a scenario where my client got > bounced for not having matching EvictionPolicy compared to already deployed > servers. > > Or do you mean that we ignore cfg in getOrCreateCaches() if name is matched > to already existing cache? > > I am worried about a usability issue where a stale client occassionally > writes entries of incorrect type into a cache or uses improper atomicity > mode. > > Regards, > > -- > Ilya Kasnacheev > > 2017-10-12 2:07 GMT+03:00 Denis Magda <dma...@apache.org>: > >> 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.kasnach...@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 >> >>
