Avoid closing caches on client during cluster restart - determining it's the same cache

[Ilya Kasnacheev]

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

[dmagda]

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 <[hidden email]> 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

[Ilya Kasnacheev]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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
>
>

[dmagda]

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 <[hidden email]> 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 <[hidden email]>:
>
>> 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 <[hidden email]>
>> 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
>>
>>