November 2014 - infinispan-issues

[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: ---------------------------------------- That's not too easy... you will either have to patch Infinispan and build your own JARs, or override/extend {{SpringEmbeddedCacheManagerFactoryBean}}, {{SpringEmbeddedCacheManager}} and {{SpringCache}} (the last one has the {{put()}} call). > 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 (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4983) Public API for tracking completion of Infinispan work for a given user transaction

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4983?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4983: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3098 > Public API for tracking completion of Infinispan work for a given user transaction > ---------------------------------------------------------------------------------- > > Key: ISPN-4983 > URL: https://issues.jboss.org/browse/ISPN-4983 > Project: Infinispan > Issue Type: Feature Request > Reporter: Randall Hauch > Assignee: Pedro Ruivo > Labels: modeshape > Fix For: 7.1.0.Alpha1 > > > When using Infinispan with user transactions, Infinispan will persist the changes to the cache store using a synchronization on the user transaction. This means the persistence operation begins when the user transaction has committed. However, components using Infinispan will likely want to know when Infinispan's work has completed for a given transaction. > In Infinispan 6, it was possible to do this by registering a transaction listener: > {code} > org.infinispan.Cache cache = ... > javax.transaction.Transaction activeTransaction = ... > org.infinispan.transaction.TransactionTable txnTable = cache.getAdvancedCache().getComponentRegistry().getComponent(TransactionTable.class); > org.infinispan.transaction.xa.GlobalTransaction ispnTxID = txnTable.getLocalTransaction(activeTransaction).getGlobalTransaction(); > {code} > We'd then use the {{GlobalTransaction}} in our {{@Listener}}: > {code} > @Listener > class TxnListener { > @TransactionCompleted > public void transactionCompleted( TransactionCompletedEvent event ) { > if ( !event.isOriginLocal() ) return; > GlobalTransaction eventIspnTransaction = event.getGlobalTransaction(); > if (eventIspnTransaction == null || > ispnTxID.getId() != eventIspnTransaction.getId()) return; > if ( !event.isSuccessful() ) { > // do stuff > } else { > // do other stuff > } > } > {code} > However, this is no longer possible in Infinispan 7 since these classes were moved to an "impl" package. > Can we please have a public API to be notified when Infinispan has complete its work for a specific user transaction? It doesn't have to be like it was in 6, but ModeShape needs something (see MODE-2353 for details). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4645) Many XSD default values do not match the defaults from the corresponding configuration builder

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4645?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4645: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167433 > Many XSD default values do not match the defaults from the corresponding configuration builder > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4645 > URL: https://issues.jboss.org/browse/ISPN-4645 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Alan Field > Fix For: 7.0.0.CR2 > > > Some examples from the 7.0 xsd: > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > There are several others. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

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

by Uma k (JIRA)

[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ] Uma k commented on ISPN-3128: ----------------------------- How can we change in spring cache to use putforexternalread instead of put. I simply want to use putforexternalread instead of put. I am not using CachePut in any other places. So I don't have issues. > 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 (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4645) Many XSD default values do not match the defaults from the corresponding configuration builder

by Alan Field (JIRA)

[ https://issues.jboss.org/browse/ISPN-4645?page=com.atlassian.jira.plugin.... ] Alan Field commented on ISPN-4645: ---------------------------------- [~dan.berindei] sent another pull request for this > Many XSD default values do not match the defaults from the corresponding configuration builder > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4645 > URL: https://issues.jboss.org/browse/ISPN-4645 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Alan Field > Fix For: 7.0.0.CR2 > > > Some examples from the 7.0 xsd: > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > There are several others. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4645) Many XSD default values do not match the defaults from the corresponding configuration builder

by Alan Field (JIRA)

[ https://issues.jboss.org/browse/ISPN-4645?page=com.atlassian.jira.plugin.... ] Alan Field updated ISPN-4645: ----------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/2902, https://github.com/infinispan/infinispan/pull/2966, https://github.com/infinispan/infinispan/pull/3097 (was: https://github.com/infinispan/infinispan/pull/2902, https://github.com/infinispan/infinispan/pull/2966) > Many XSD default values do not match the defaults from the corresponding configuration builder > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4645 > URL: https://issues.jboss.org/browse/ISPN-4645 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Alan Field > Fix For: 7.0.0.CR2 > > > Some examples from the 7.0 xsd: > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > There are several others. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4944) Improve HR client security test coverage

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4944?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4944: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Alpha1 7.1.0.Final Resolution: Done > Improve HR client security test coverage > ---------------------------------------- > > Key: ISPN-4944 > URL: https://issues.jboss.org/browse/ISPN-4944 > Project: Infinispan > Issue Type: Feature Request > Components: Test Suite - Server > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 7.1.0.Alpha1, 7.1.0.Final > > > Extends security test for HR client so that the tests cover all HR operations (available on [Remote cache|https://docs.jboss.org/infinispan/7.0/apidocs/org/infinispan/client...]) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4921) Tests in "smoke" TestNG group do not run in default profile

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4921?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4921: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1167401|https://bugzilla.redhat.com/show_bug.cgi?id=1167401] from NEW to POST > Tests in "smoke" TestNG group do not run in default profile > ----------------------------------------------------------- > > Key: ISPN-4921 > URL: https://issues.jboss.org/browse/ISPN-4921 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.CR2 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Final > > > All occurences of > {code:java} > @Test(groups = "functional,smoke",...... > {code} > should be changed to > {code:java} > @Test(groups = {"functional", "smoke"} .... > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4665) Define "smoke" test group for Infinispan test suite

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4665?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4665: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1167401|https://bugzilla.redhat.com/show_bug.cgi?id=1167401] from NEW to POST > Define "smoke" test group for Infinispan test suite > --------------------------------------------------- > > Key: ISPN-4665 > URL: https://issues.jboss.org/browse/ISPN-4665 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core, Test Suite - Server > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Final > > > The goal is to define a new TestNG group called "smoke" and add some tests into this group. Let's go over Infinispan test suite and choose tests that verify basic functionality of each (or most of) feature but they don't have to test it in depth. > Running tests in "smoke" group should take just a few minutes. We don't need thousands of tests here. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4983) Public API for tracking completion of Infinispan work for a given user transaction

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4983?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4983: ------------------------------ Status: Open (was: New) > Public API for tracking completion of Infinispan work for a given user transaction > ---------------------------------------------------------------------------------- > > Key: ISPN-4983 > URL: https://issues.jboss.org/browse/ISPN-4983 > Project: Infinispan > Issue Type: Feature Request > Reporter: Randall Hauch > Assignee: Pedro Ruivo > Labels: modeshape > Fix For: 7.1.0.Alpha1 > > > When using Infinispan with user transactions, Infinispan will persist the changes to the cache store using a synchronization on the user transaction. This means the persistence operation begins when the user transaction has committed. However, components using Infinispan will likely want to know when Infinispan's work has completed for a given transaction. > In Infinispan 6, it was possible to do this by registering a transaction listener: > {code} > org.infinispan.Cache cache = ... > javax.transaction.Transaction activeTransaction = ... > org.infinispan.transaction.TransactionTable txnTable = cache.getAdvancedCache().getComponentRegistry().getComponent(TransactionTable.class); > org.infinispan.transaction.xa.GlobalTransaction ispnTxID = txnTable.getLocalTransaction(activeTransaction).getGlobalTransaction(); > {code} > We'd then use the {{GlobalTransaction}} in our {{@Listener}}: > {code} > @Listener > class TxnListener { > @TransactionCompleted > public void transactionCompleted( TransactionCompletedEvent event ) { > if ( !event.isOriginLocal() ) return; > GlobalTransaction eventIspnTransaction = event.getGlobalTransaction(); > if (eventIspnTransaction == null || > ispnTxID.getId() != eventIspnTransaction.getId()) return; > if ( !event.isSuccessful() ) { > // do stuff > } else { > // do other stuff > } > } > {code} > However, this is no longer possible in Infinispan 7 since these classes were moved to an "impl" package. > Can we please have a public API to be notified when Infinispan has complete its work for a specific user transaction? It doesn't have to be like it was in 6, but ModeShape needs something (see MODE-2353 for details). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014