+1 for deprecation in 2.7 and removal in 3.0. (binding) :) I do not see any reason to use local cache instead of CHM, even for testing.
чт, 26 июл. 2018 г. в 17:05, Pavel Kovalenko <jokse...@gmail.com>: > Stan, > > I don't think that it is a good way to spawn such crutches in the codebase > for extra rare cases of some of the users. > I think we should do it in right way or do nothing and just remove LOCAL > caches completely. > > 2018-07-25 16:19 GMT+03:00 Stanislav Lukyanov <stanlukya...@gmail.com>: > > > In my view the approach in implementing LOCAL caches isn’t supposed to be > > highly efficient – just a > > functional workaround for the existing users of LOCAL cache. > > Moreover, if the workaround is easy but slightly awkward it isn’t a bad > > thing – a user needs to understand that their use case > > isn't directly supported and they shouldn’t expect too much of it. > > That’s a drawback of the existing LOCAL cache – it appears as a > > well-supported use case in the API, but if one actually tries to use it > > they’ll see lower performance and more awkward behavior than what they > > could expect. > > > > Stan > > > > From: Pavel Kovalenko > > Sent: 25 июля 2018 г. 15:27 > > To: dev@ignite.apache.org > > Subject: Re: Deprecating LOCAL cache > > > > It's not easy to just make such caches as PARTITIONED with NodeFilter. > > Even in the case when a node is not affinity node for this cache we > create > > entities like GridClientPartitionTopology for such caches on all nodes. > > These caches participate in the exchange, calculate affinity, etc. on all > > nodes. > > If you create 1 instance of local cache on N nodes you will get N^2 > useless > > entities which will eat resources. > > So, this approach should be carefully analyzed before the proposed > > implementation. > > > > 2018-07-25 11:58 GMT+03:00 Dmitrii Ryabov <somefire...@gmail.com>: > > > > > +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 <dsetrak...@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.kuliche...@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 < > > > > > stanlukya...@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 > > > > > > > > > > > > > > > > > > > > > > >
