ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitrii Ryabov <somefire...@gmail.com>
Subject Re: Deprecating LOCAL cache
Date Wed, 25 Jul 2018 08:58:41 GMT
+1 to make LOCAL as filtered PARTITIONED cache. I think it would be much
easier and faster than fixing all bugs.

2018-07-25 11:51 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> I would stay away from deprecating such huge pieces as a whole LOCAL cache.
> In retrospect, we should probably not even have LOCAL caches, but now I am
> certain that it is used by many users.
>
> I would do one of the following, whichever one is easier:
>
>    - Fix the issues found with LOCAL caches, including persistence support
>    - Implement LOCAL caches as PARTITIONED caches over the local node. In
>    this case, we would have to hide any distribution-related config from
>    users, like affinity function, for example.
>
> D.
>
> On Wed, Jul 25, 2018 at 9:05 AM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > It sounds like the main drawback of LOCAL cache is that it's implemented
> > separately and therefore has to be maintained separately. If that's the
> > only issue, why not keep LOCAL cache mode on public API, but implement it
> > as a PARTITIONED cache with a node filter forcefully set? That's similar
> to
> > what we do with REPLICATED caches which are actually PARTITIONED with
> > infinite number of backups.
> >
> > This way we fix the issues described by Stan and don't have to deprecate
> > anything.
> >
> > -Val
> >
> > On Wed, Jul 25, 2018 at 12:53 AM Stanislav Lukyanov <
> > stanlukyanov@gmail.com>
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > I’d like to start a discussion about the deprecation of the LOCAL
> caches.
> > >
> > > LOCAL caches are an edge-case functionality
> > > I haven’t done any formal analysis, but from my experience LOCAL caches
> > > are needed very rarely, if ever.
> > > I think most usages of LOCAL caches I’ve seen were misuses: the users
> > > actually needed a simple HashMap, or an actual PARTITIONED cache.
> > >
> > > LOCAL caches are easy to implement on top of PARTITIONED
> > > If one requires a LOCAL cache (which is itself questionable, as
> discussed
> > > above) it is quite easy to implement one on top of PARTITIONED cache.
> > > A node filter of form `node -> node.id().equals(localNodeId)` is
> enough
> > > to make the cache to be stored on the node that created it.
> > > Locality of access to the cache (i.e. making it unavailable from other
> > > nodes) can be achieved on the application level.
> > >
> > > LOCAL caches are hard to maintain
> > > A quick look at the open issues mentioning “local cache” suggests that
> > > this is a corner case for implementation of many Ignite features:
> > >
> > > https://issues.apache.org/jira/issues/?jql=text%20~%20%
> > 22local%20cache%22%20and%20%20project%20%3D%20IGNITE%
> > 20and%20status%20%3D%20open
> > > In particular, a recent SO question brought up the fact that LOCAL
> caches
> > > don’t support native persistence:
> > >
> > > https://stackoverflow.com/questions/51511892/how-to-
> > configure-persistent-storage-for-apache-ignite-cache
> > > Having to ask ourselves “how does it play with LOCAL caches” every time
> > we
> > > write any code in Ignite seems way to much for the benefits we gain
> from
> > it.
> > >
> > > Proposal
> > > Let’s deprecate LOCAL caches in 2.x and remove them in 3.0.
> > > As a part of deprecation let’s do the following:
> > > - Put @Deprecated on the CacheMode.LOCAL
> > > - Print a warning every time a LOCAL cache is created
> > > - Remove all mentions of LOCAL caches from readme.io, if any, except
> for
> > > the page about cache modes
> > > - On the page about cache modes explain that LOCAL is deprecated and
> can
> > > be replaced with a PARTITIONED cache with a node filter
> > >
> > > Thanks,
> > > Stan
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message