ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Avoid closing caches on client during cluster restart - determining it's the same cache
Date Mon, 16 Oct 2017 09:29:39 GMT
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 <dmagda@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.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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message