May 2019 - infinispan-issues - Jboss List Archives

by Diego Lovison (Jira)

Diego Lovison created ISPN-10198: ------------------------------------ Summary: Zing ' Key: ISPN-10198 URL: https://issues.jboss.org/browse/ISPN-10198 Project: Infinispan Issue Type: Bug Reporter: Diego Lovison -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9027) Distinguishing multiple server Store configurations is impossible

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9027?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9027: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6905, https://github.com/infinispan/infinispan/pull/6922 (was: https://github.com/infinispan/infinispan/pull/6905) > Distinguishing multiple server Store configurations is impossible > ----------------------------------------------------------------- > > Key: ISPN-9027 > URL: https://issues.jboss.org/browse/ISPN-9027 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Affects Versions: 9.2.1.Final > Reporter: Sebastian Laskawiec > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > Attachments: clustered.xml > > > h3. Problem description > One of our users reported that when using two Deployed Cache Stores, their configuration gets overridden and both behaves as if they had the same configuration. Here's an example: > {code} > <distributed-cache name="cassandracache1" owners="2" segments="256" mode="SYNC"> > <store name="store1" class="org.infinispan.persistence.cassandra.CassandraStore" preload="true"> > <property name="autoCreateKeyspace"> > true > </property> > <property name="keyspace"> > Infinispan > </property> > <property name="entryTable"> > InfinispanEntries > </property> > <property name="servers"> > 172.17.0.2[9042] > </property> > </store> > </distributed-cache> > <distributed-cache name="cassandracache2" owners="2" segments="256" mode="SYNC"> > <store name="store2" class="org.infinispan.persistence.cassandra.CassandraStore" preload="true"> > <property name="autoCreateKeyspace"> > true > </property> > <property name="keyspace"> > Infinispan > </property> > <property name="entryTable"> > InfinispanEntries1 > </property> > <property name="servers"> > 172.17.0.2[9042] > </property> > </store> > </distributed-cache> > {code} > Both caches ({{cassandracache1}} and {{cassandracache2}}) use the same {{entryTable}} which is set to {{InfinispanEntries1}}. > h3. Investigation > {{CacheStoreFactory}} implementation were created to fabricate Loader/Writer instance based on parsed configuration (via {{createInstance}} method). This method receives from {{PersistenceManagerImpl}} an instance of an {{AbstractStoreConfiguration}} (here's an example (1)) two times - once per each parsed configuration. The parsing part seems OK but we do not parse Cache Store Name, which makes differentiating both configuration impossible. > h3. Proposed fix > * Add {{name}} attribute to {{StoreConfiguration}}. > * Either add an explicit parameter to {{CacheStoreFactory#createInstance(StoreConfiguration cfg, String cacheStoreName)}} or scan for Cache Store name in both implementations ({{DeployedCacheStoreFactory}} and {{LocalClassLoaderCacheStoreFactory}}. > {code} > (1) AbstractStoreConfiguration [attributes=DeployedStoreConfiguration = [fetchPersistentState=false, purgeOnStartup=false, ignoreModifications=false, preload=true, shared=false, transactional=false, maxBatchSize=100, properties={keyspace=Infinispan, connectionPool.poolTimeoutMillis=5, entryTable=InfinispanEntries, connectionPool.idleTimeoutSeconds=120, connectionPool.heartbeatIntervalSeconds=30, autoCreateKeyspace=true, servers=172.17.0.2[9042]}, customStoreClassName=org.infinispan.persistence.cassandra.CassandraStore], async=AsyncStoreConfiguration [attributes=AsyncStoreConfiguration = [enabled=false, modificationQueueSize=1024, threadPoolSize=1]], singletonStore=SingletonStoreConfiguration [attributes=SingletonStoreConfiguration = [enabled=false, push-state-timeout=10000, push-state-when-coordinator=true]]] > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7875) Infinispan as Spring Data backend

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-7875?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-7875: ------------------------------- Status: Open (was: New) > Infinispan as Spring Data backend > --------------------------------- > > Key: ISPN-7875 > URL: https://issues.jboss.org/browse/ISPN-7875 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Katia Aresti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7875) Infinispan as Spring Data backend

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-7875?page=com.atlassian.jira.plugin.... ] Work on ISPN-7875 started by Katia Aresti. ------------------------------------------ > Infinispan as Spring Data backend > --------------------------------- > > Key: ISPN-7875 > URL: https://issues.jboss.org/browse/ISPN-7875 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Katia Aresti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9698) SpringCache doesn't unwrap null values in get(key, valueLoader) overload

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9698?page=com.atlassian.jira.plugin.... ] Katia Aresti closed ISPN-9698. ------------------------------ Resolution: Duplicate Issue > SpringCache doesn't unwrap null values in get(key, valueLoader) overload > ------------------------------------------------------------------------ > > Key: ISPN-9698 > URL: https://issues.jboss.org/browse/ISPN-9698 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 9.4.1.Final > Reporter: Jeff Skjonsby > Assignee: Katia Aresti > Priority: Major > > This test case fails: > {code:java} > @Test > public void nullValuesAreNotUnwrapped() { > Configuration config = new ConfigurationBuilder().build(); > SpringEmbeddedCacheManager cacheManager = new SpringEmbeddedCacheManager(new DefaultCacheManager(config)); > SpringCache cache = cacheManager.getCache("foo"); > cache.put("nullable", null); > assertNull(cache.get("nullable", () -> "a")); > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10171) Spring Cache sync locking does not work

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10171?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10171: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6897, https://github.com/infinispan/infinispan/pull/6921 (was: https://github.com/infinispan/infinispan/pull/6897) > Spring Cache sync locking does not work > --------------------------------------- > > Key: ISPN-10171 > URL: https://issues.jboss.org/browse/ISPN-10171 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 9.4.11.Final, 10.0.0.Beta4 > Environment: > mvn -version > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00) > Maven home: /usr/local/Cellar/maven/3.6.0/libexec > Java version: 11.0.1, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/openjdk-11.0.1.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac" > Reporter: Rens van Leeuwen > Assignee: Katia Aresti > Priority: Major > > With ISPN-7224/https://github.com/infinispan/infinispan/pull/5262, an implementation was written to support a synchronous get that implements Spring Cache's {{@Cacheable(sync = true)}}. > That seems to work well in isolation, but not in an integrated way. By that I mean, that the implementation of {{SpringCache}} maintains its own {{ReentrantLock}}s in each instance. > Zooming out a bit, this is part of the call stack when the {{SpringCache}} instance is looked up during handling the {{@Cacheable(sync = true)}} annotation: > {noformat} > CacheInterceptor.invoke(MethodInvocation) (org.springframework.cache.interceptor) > CacheAspectSupport.execute(CacheOperationInvoker, Object, Method, Object[]) (org.springframework.cache.interceptor) > CacheOperationContexts in CacheAspectSupport.CacheOperationContexts(Collection<? extends CacheOperation>, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor) > CacheAspectSupport.getOperationContext(CacheOperation, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor) > CacheOperationContext in CacheAspectSupport.CacheOperationContext(CacheOperationMetadata, Object[], Object) (org.springframework.cache.interceptor) > CacheAspectSupport.getCaches(CacheOperationInvocationContext<CacheOperation>, CacheResolver) (org.springframework.cache.interceptor) > AbstractCacheResolver.resolveCaches(CacheOperationInvocationContext<?>) (org.springframework.cache.interceptor) > ----->> SpringEmbeddedCacheManager.getCache(String) (org.infinispan.spring.embedded.provider) > SpringCache.SpringCache(BasicCache) (org.infinispan.spring.common.provider) > SpringCache.SpringCache(BasicCache, long, long) (org.infinispan.spring.common.provider) > {noformat} > The problem with this is, that for each turn the interceptor handles the request a *new instance* of the {{SpringCache}} is made in the {{SpringEmbeddedCacheManager}}, rendering the use of the {{ReentrantLock}} mechanism useless to a certain extent, because multiple threads accessing the {{@Cacheable(sync = true)}} method will each have their own {{SpringCache}} and corresponding {{ReentrantLock}}. > In turn, there is no locking at all, and each thread will be executing the (assumed to be) expensive code that is intended to be cached. > -- > I'm intending to write a patch for this, but this would be the first time I commit to an open source project (bear with me ;)). I'll try to provide a pull request for this. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10197) SoftIndexFileStoreStressTest is broken

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10197?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10197: ------------------------------ Status: Open (was: New) > SoftIndexFileStoreStressTest is broken > -------------------------------------- > > Key: ISPN-10197 > URL: https://issues.jboss.org/browse/ISPN-10197 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.13.Final > Reporter: Jonathan Halliday > Priority: Major > Fix For: 10.0.0.Beta4 > > > SoftIndexFileStoreStressTest fails as SoftIndexfileStore doesn't handle AdvancedCacheLoader.process > java.lang.UnsupportedOperationException: Should call processEntries! > at org.infinispan.persistence.spi.AdvancedCacheLoader.process(AdvancedCacheLoader.java:54) > at org.infinispan.persistence.sifs.SoftIndexFileStoreStressTest.testMethod(SoftIndexFileStoreStressTest.java:111) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10197) SoftIndexFileStoreStressTest is broken

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10197?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10197: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6919 > SoftIndexFileStoreStressTest is broken > -------------------------------------- > > Key: ISPN-10197 > URL: https://issues.jboss.org/browse/ISPN-10197 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.13.Final > Reporter: Jonathan Halliday > Priority: Major > Fix For: 10.0.0.Beta4 > > > SoftIndexFileStoreStressTest fails as SoftIndexfileStore doesn't handle AdvancedCacheLoader.process > java.lang.UnsupportedOperationException: Should call processEntries! > at org.infinispan.persistence.spi.AdvancedCacheLoader.process(AdvancedCacheLoader.java:54) > at org.infinispan.persistence.sifs.SoftIndexFileStoreStressTest.testMethod(SoftIndexFileStoreStressTest.java:111) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10197) SoftIndexFileStoreStressTest is broken

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10197?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10197: ------------------------------ Fix Version/s: 10.0.0.Beta4 > SoftIndexFileStoreStressTest is broken > -------------------------------------- > > Key: ISPN-10197 > URL: https://issues.jboss.org/browse/ISPN-10197 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.13.Final > Reporter: Jonathan Halliday > Priority: Major > Fix For: 10.0.0.Beta4 > > > SoftIndexFileStoreStressTest fails as SoftIndexfileStore doesn't handle AdvancedCacheLoader.process > java.lang.UnsupportedOperationException: Should call processEntries! > at org.infinispan.persistence.spi.AdvancedCacheLoader.process(AdvancedCacheLoader.java:54) > at org.infinispan.persistence.sifs.SoftIndexFileStoreStressTest.testMethod(SoftIndexFileStoreStressTest.java:111) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10197) SoftIndexFileStoreStressTest is broken

by Jonathan Halliday (Jira)

Jonathan Halliday created ISPN-10197: ---------------------------------------- Summary: SoftIndexFileStoreStressTest is broken Key: ISPN-10197 URL: https://issues.jboss.org/browse/ISPN-10197 Project: Infinispan Issue Type: Bug Affects Versions: 9.4.13.Final Reporter: Jonathan Halliday SoftIndexFileStoreStressTest fails as SoftIndexfileStore doesn't handle AdvancedCacheLoader.process java.lang.UnsupportedOperationException: Should call processEntries! at org.infinispan.persistence.spi.AdvancedCacheLoader.process(AdvancedCacheLoader.java:54) at org.infinispan.persistence.sifs.SoftIndexFileStoreStressTest.testMethod(SoftIndexFileStoreStressTest.java:111) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 May 2019