ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Zinoviev <zaleslaw....@gmail.com>
Subject Re: Deprecating LOCAL cache
Date Thu, 26 Jul 2018 13:57:16 GMT
Sorry, guys, I'll put my 1 cent

I'd like this idea  "Implement LOCAL caches as PARTITIONED caches over the
local node."
It make sense for examples/testing in pseudo-distributed mode and so far.

But I think that the deprecation based on user-list mentions is a wrong
way. Please look here
https://github.com/search?q=%22CacheMode.LOCAL%22+%26+ignite&type=Code
There a lot of hello world examples with LOCAL mode.

And of course, we can ask about that on user-list, not here, to vote for
the deprecation like this.

2018-07-26 11:23 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:

> I meant LOCAL + non-LOCAL transactions of course.
>
> On Wed, Jul 25, 2018 at 10:42 PM Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
> > Vladimir,
> >
> > Are you suggesting that a user cannot span more than one local cache in a
> > cross cache LOCAL transactions. This is extremely surprising to me, as it
> > would require almost no effort to support it. As far as mixing the local
> > caches with distributed caches, then I agree, cross-cache transactions do
> > not make sense.
> >
> > I am not sure why deprecating local caches has become a pressing issue. I
> > can see that there are a few bugs, but why not just fix them and move on?
> > Can someone explain why supporting LOCAL caches is such a burden?
> >
> > Having said that, I am not completely opposed to deprecating LOCAL
> caches.
> > I just want to know why.
> >
> > D.
> >
> > On Wed, Jul 25, 2018 at 10:55 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > Dima,
> > >
> > > LOCAL cache adds very little value to the product. It doesn't support
> > > cross-cache transactions, consumes a lot of memory, much slower than
> any
> > > widely-used concurrent hash map. Let's go the same way as Java - mark
> > LOCAL
> > > cache as "deprecated for removal", and then remove it in 3.0.
> > >
> > > On Wed, Jul 25, 2018 at 12:10 PM Dmitrii Ryabov <somefireone@gmail.com
> >
> > > wrote:
> > >
> > > > +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