Deprecating LOCAL cache

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Deprecating LOCAL cache

Stanislav Lukyanov
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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Nikolay Izhikov-2
Huge +1 from me.

One more SO question about LOCAL caches - https://stackoverflow.com/questions/49051079/is-it-possible-to-perform-sql-query-with-distributed-join-over-a-local-cache-and

"It is not possible to perform joins (both distributed an co-located) between LOCAL and PARTITIONED caches. The workaround is to use two PARTITIONED caches."

В Ср, 25/07/2018 в 10:52 +0300, Stanislav Lukyanov пишет:

> 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,
> St

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Valentin Kulichenko
In reply to this post by Stanislav Lukyanov
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 <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

RE: Deprecating LOCAL cache

Stanislav Lukyanov
To me it also raises a question of having REPLICATED :)
But that might seem too radical, so let’s decide on the LOCAL first.

I don’t mind keeping LOCAL as an alias for PARTITIONED with a default node filter,
but I don’t see much benefit in it. Why to have a shortcut for something used by 1% (or less?) when there is a way to do the same with a few more lines?
Compatibility is a reason to keep things as they are, but that’s why I suggest to only remove it in 3.0 when we’ll have a chance to do some cleaning.

Stan

From: Valentin Kulichenko
Sent: 25 июля 2018 г. 11:09
To: [hidden email]
Subject: Re: Deprecating LOCAL cache

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

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

dsetrakyan
In reply to this post by Valentin Kulichenko
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 <
[hidden email]> 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 <
> [hidden email]>
> 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:
> >
> > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

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

> 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 <
> [hidden email]> 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 <
> > [hidden email]>
> > 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:
> > >
> > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

RE: Deprecating LOCAL cache

Stanislav Lukyanov
In reply to this post by dsetrakyan
Deprecating something doesn’t mean an immediate impact on users.
By deprecating LOCAL caches we would be saying that this functionality has limited support, has issues and will be removed *eventually*.
By the time of 3.0 we’ll have a better idea about how many users are affected as they will be notified by deprecation and code warnings.
If the number is higher than we anticipate, we can postpone removal until 4.0 and/or present a different solution/feature.

In any case, removal of LOCAL caches would hardly be the worst thing in 3.0 in terms of compatibility.

Stan

From: Dmitriy Setrakyan
Sent: 25 июля 2018 г. 11:51
To: dev
Subject: Re: Deprecating LOCAL cache

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 <
[hidden email]> 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 <
> [hidden email]>
> 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:
> >
> > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Pavel Kovalenko
In reply to this post by Dmitrii Ryabov
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 <[hidden email]>:

> +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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <
> > > [hidden email]>
> > > 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:
> > > >
> > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Vladimir Ozerov
In reply to this post by Dmitrii Ryabov
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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <
> > > [hidden email]>
> > > 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:
> > > >
> > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Dmitriy Pavlov
In reply to this post by Dmitrii Ryabov
Hi Igniters,

I've never seen the LOCAL cache in the user list for 1 year. I've tried to
search in archives and found only that mention
http://apache-ignite-users.70518.x6.nabble.com/LOCAL-cache-and-EntryProcessor-td7419.html
in
2016.

Who can provide any additional usage examples?

My vote goes to deprecate until it is not clear for everyone, that LOCAL
cache is widely used feature.

Sincerely,
Dmitriy Pavlov

ср, 25 июл. 2018 г. в 12:10, Dmitrii Ryabov <[hidden email]>:

> +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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <
> > > [hidden email]>
> > > 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:
> > > >
> > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Ilya Kasnacheev
In reply to this post by Vladimir Ozerov
Hello!

I have never seen the usage of LOCAL cache so far, so I am for its
deprecation.

Regards,

--
Ilya Kasnacheev

2018-07-25 12:55 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > 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:
> > > > >
> > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Dmitrii Ryabov
In reply to this post by Vladimir Ozerov
Vladimir, do we have a ticket for cross-cache transactions with LOCAL
cache? I can't find it. In my task I met this situation in tests and I want
to fail such tests with link to this ticket.

2018-07-25 12:55 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > 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:
> > > > >
> > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Dmitrii Ryabov
In reply to this post by Stanislav Lukyanov
Vladimir, do we have a ticket for cross-cache transactions with LOCAL
cache? I can't find it. In my task I met this situation in tests and I want
to fail such tests with link to this ticket. Also documentation in readme.io
say nothing about cross-cache failures with LOCAL cache.

ср, 25 июл. 2018 г., 13:55 Stanislav Lukyanov <[hidden email]>:

> To me it also raises a question of having REPLICATED :)
> But that might seem too radical, so let’s decide on the LOCAL first.
>
> I don’t mind keeping LOCAL as an alias for PARTITIONED with a default node
> filter,
> but I don’t see much benefit in it. Why to have a shortcut for something
> used by 1% (or less?) when there is a way to do the same with a few more
> lines?
> Compatibility is a reason to keep things as they are, but that’s why I
> suggest to only remove it in 3.0 when we’ll have a chance to do some
> cleaning.
>
> Stan
>
> From: Valentin Kulichenko
> Sent: 25 июля 2018 г. 11:09
> To: [hidden email]
> Subject: Re: Deprecating LOCAL cache
>
> 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 <
> [hidden email]>
> 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
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Sergey Kozlov
In reply to this post by Pavel Kovalenko
Not sure that we can create cache with same name by different clients for
this approach.

On Wed, Jul 25, 2018 at 12:35 PM, Pavel Kovalenko <[hidden email]>
wrote:

> 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 <[hidden email]>:
>
> > +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 <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > 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:
> > > > >
> > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > >
> > > >
> > >
> >
>



--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Reply | Threaded
Open this post in threaded view
|

RE: Deprecating LOCAL cache

Stanislav Lukyanov
In reply to this post by Pavel Kovalenko
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: [hidden email]
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 <[hidden email]>:

> +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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <
> > > [hidden email]>
> > > 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:
> > > >
> > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > >
> > >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

dsetrakyan
In reply to this post by Vladimir Ozerov
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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > 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:
> > > > >
> > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Vladimir Ozerov
I meant LOCAL + non-LOCAL transactions of course.

On Wed, Jul 25, 2018 at 10:42 PM Dmitriy Setrakyan <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <
> > > > [hidden email]> 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 <
> > > > > [hidden email]>
> > > > > 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:
> > > > > >
> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

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

> I meant LOCAL + non-LOCAL transactions of course.
>
> On Wed, Jul 25, 2018 at 10:42 PM Dmitriy Setrakyan <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > > 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 <[hidden email]
> >:
> > > >
> > > > > 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 <
> > > > > [hidden email]> 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 <
> > > > > > [hidden email]>
> > > > > > 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:
> > > > > > >
> > > > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Pavel Kovalenko
In reply to this post by Stanislav Lukyanov
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 <[hidden email]>:

> 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: [hidden email]
> 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 <[hidden email]>:
>
> > +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 <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > 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:
> > > > >
> > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > >
> > > >
> > >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating LOCAL cache

Anton Vinogradov-2
+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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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: [hidden email]
> > 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 <[hidden email]>:
> >
> > > +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 <[hidden email]>:
> > >
> > > > 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 <
> > > > [hidden email]> 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 <
> > > > > [hidden email]>
> > > > > 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:
> > > > > >
> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=text%20~%20%">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
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
12