July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching

by Mike Noordermeer (JIRA)

[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ] Mike Noordermeer commented on ISPN-3128: ---------------------------------------- I think sync replication has a couple of drawbacks: * Whole datasets in memory, something that would probably double memory requirements for the cache. * Dependencies between nodes: if node A goes down, other nodes may be unavailable as well, because they will wait until node A is removed from the cluster. * Your cache objects need to be serializable in order to be able to replicate them. This is a fairly old issue, and in the meantime we have been using a mix of invalidating async and replicating sync caches, dependent on the requirements. In case of the invalidating async caches, we need to make sure the data is only necessary on one host at the same time (e.g., user data with session affinity, things like that) > Better support for (Spring) read caching > ---------------------------------------- > > Key: ISPN-3128 > URL: https://issues.jboss.org/browse/ISPN-3128 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Affects Versions: 5.3.0.Beta2 > Environment: Spring 3.1+ > Reporter: Mike Noordermeer > Assignee: Sebastian Łaskawiec > > We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation. > As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario: > - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode > - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y) > - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated* > - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc... > The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes. > In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues: > - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour). > - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour. > Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-3128: ------------------------------------------- I've just read the feature request and I think using a [synchronous, replicated cache|http://infinispan.org/docs/dev/user_guide/user_guide.html#replicate...] might be a good fit. So if you update an entry from a Node X, Node Y will get an update in a synchronous fashion. Of course this has nothing to do with invalidation but you should get the same effect from client perspective. The downside of this approach is that you need a lot of memory (your entire data set need to fit all nodes). However [off heap|http://infinispan.org/docs/dev/user_guide/user_guide.html#storage_type] as well [eviction|http://infinispan.org/docs/dev/user_guide/user_guide.html#evicti...] might be a way out. Perhaps you'd like to give it a go? > Better support for (Spring) read caching > ---------------------------------------- > > Key: ISPN-3128 > URL: https://issues.jboss.org/browse/ISPN-3128 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Affects Versions: 5.3.0.Beta2 > Environment: Spring 3.1+ > Reporter: Mike Noordermeer > Assignee: Gustavo Fernandes > > We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation. > As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario: > - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode > - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y) > - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated* > - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc... > The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes. > In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues: > - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour). > - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour. > Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-3128: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Gustavo Fernandes) > Better support for (Spring) read caching > ---------------------------------------- > > Key: ISPN-3128 > URL: https://issues.jboss.org/browse/ISPN-3128 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Affects Versions: 5.3.0.Beta2 > Environment: Spring 3.1+ > Reporter: Mike Noordermeer > Assignee: Sebastian Łaskawiec > > We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation. > As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario: > - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode > - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y) > - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated* > - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc... > The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes. > In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues: > - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour). > - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour. > Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8012) Console: UI to execute PUT operations

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8012?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8012: ------------------------------- Component/s: Console > Console: UI to execute PUT operations > ------------------------------------- > > Key: ISPN-8012 > URL: https://issues.jboss.org/browse/ISPN-8012 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8013) Console: UI to execute query and display results

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8013?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8013: ------------------------------- Component/s: Console > Console: UI to execute query and display results > ------------------------------------------------ > > Key: ISPN-8013 > URL: https://issues.jboss.org/browse/ISPN-8013 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8014) Console: UI to execute DELETE operations

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8014?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8014: ------------------------------- Component/s: Console > Console: UI to execute DELETE operations > ---------------------------------------- > > Key: ISPN-8014 > URL: https://issues.jboss.org/browse/ISPN-8014 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8015) Console: Browse content of a cache

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8015?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8015: ------------------------------- Component/s: Console > Console: Browse content of a cache > ---------------------------------- > > Key: ISPN-8015 > URL: https://issues.jboss.org/browse/ISPN-8015 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8016) Console: Implement Counter Operations

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8016?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8016: ------------------------------- Component/s: Console > Console: Implement Counter Operations > ------------------------------------- > > Key: ISPN-8016 > URL: https://issues.jboss.org/browse/ISPN-8016 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8011) Console: UI to execute GET operations

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8011?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8011: ------------------------------- Component/s: Console > Console: UI to execute GET operations > ------------------------------------- > > Key: ISPN-8011 > URL: https://issues.jboss.org/browse/ISPN-8011 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7605) Remove version schemes hardcoding

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7605?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-7605: ----------------------------------- Note that {{CacheDecodeContext.extractVersion}} currently ignores topology part of {{SimpleClusteredVersion}}; this could lead to a potential bug. > Remove version schemes hardcoding > --------------------------------- > > Key: ISPN-7605 > URL: https://issues.jboss.org/browse/ISPN-7605 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Server > Reporter: Gustavo Fernandes > Assignee: Galder Zamarreño > > Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}. > The Hot Rod protocol only supports the {{NumericVersion}} format and throughout the code there is lots of hard casts to {{NumericVersion}}. > It could make sense to support other types of versions not based on {{long}} values. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017