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 |
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 |
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 > |
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 > |
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 > > > |
+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 > > > > > > |
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 > > > |
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 > > > > > > > > > > |
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 > > > > > > > > > > |
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 > > > > > > > > > > |
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 > > > > > > > > > > > > > > > |
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 > > > > > > > > > > > > > > > |
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 > > > > |
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 |
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 > > > > > > > > > > |
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 > > > > > > > > > > > > > > > |
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 > > > > > > > > > > > > > > > > > > > > > |
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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
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 > > > > > > > > > > > > > > > > |
+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 > > > > > > > > > > > > > > > > > > > > > > > |
Free forum by Nabble | Edit this page |