August 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-12207) Functional Map APIs not functional properly with invalidation cache

by Sammy Chu (Jira)

[ https://issues.redhat.com/browse/ISPN-12207?page=com.atlassian.jira.plugi... ] Sammy Chu updated ISPN-12207: ----------------------------- Attachment: ISPN-12207.source.zip > Functional Map APIs not functional properly with invalidation cache > ------------------------------------------------------------------- > > Key: ISPN-12207 > URL: https://issues.redhat.com/browse/ISPN-12207 > Project: Infinispan > Issue Type: Bug > Components: API, Core > Affects Versions: 11.0.3.Final > Reporter: Sammy Chu > Priority: Critical > Attachments: ISPN-12207.source.zip, ISPN-12207.war > > > Functional Map API not working properly when working with invalidation cache. When in a clustered environment, expecting cache put and cache remove will notify cluster members to do cache eviction when dealing when invalidation cache. But observed no cache eviction occurred in cluster members when using Functional Map APIs to deal with invalidation cache. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12207) Functional Map APIs not functional properly with invalidation cache

by Sammy Chu (Jira)

[ https://issues.redhat.com/browse/ISPN-12207?page=com.atlassian.jira.plugi... ] Sammy Chu updated ISPN-12207: ----------------------------- Attachment: ISPN-12207.war > Functional Map APIs not functional properly with invalidation cache > ------------------------------------------------------------------- > > Key: ISPN-12207 > URL: https://issues.redhat.com/browse/ISPN-12207 > Project: Infinispan > Issue Type: Bug > Components: API, Core > Affects Versions: 11.0.3.Final > Reporter: Sammy Chu > Priority: Critical > Attachments: ISPN-12207.war > > > Functional Map API not working properly when working with invalidation cache. When in a clustered environment, expecting cache put and cache remove will notify cluster members to do cache eviction when dealing when invalidation cache. But observed no cache eviction occurred in cluster members when using Functional Map APIs to deal with invalidation cache. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12207) Functional Map APIs not functional properly with invalidation cache

by Sammy Chu (Jira)

Sammy Chu created ISPN-12207: -------------------------------- Summary: Functional Map APIs not functional properly with invalidation cache Key: ISPN-12207 URL: https://issues.redhat.com/browse/ISPN-12207 Project: Infinispan Issue Type: Bug Components: API, Core Affects Versions: 11.0.3.Final Reporter: Sammy Chu Functional Map API not working properly when working with invalidation cache. When in a clustered environment, expecting cache put and cache remove will notify cluster members to do cache eviction when dealing when invalidation cache. But observed no cache eviction occurred in cluster members when using Functional Map APIs to deal with invalidation cache. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11942) JCache CacheEntryCreatedListener got TimeoutException ISPN000299 when listener calling code which accessing the created cache value

by Sammy Chu (Jira)

[ https://issues.redhat.com/browse/ISPN-11942?page=com.atlassian.jira.plugi... ] Sammy Chu updated ISPN-11942: ----------------------------- Affects Version/s: 11.0.3.Final (was: 10.1.8.Final) > JCache CacheEntryCreatedListener got TimeoutException ISPN000299 when listener calling code which accessing the created cache value > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-11942 > URL: https://issues.redhat.com/browse/ISPN-11942 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 11.0.3.Final > Reporter: Sammy Chu > Priority: Major > Attachments: ISPN-11942-fail.log, ISPN-11942-success.log, ISPN-11942.zip > > > We are running into issue when upgrading infinispan from 9.1.7.Final to 9.2.0.Final and got the TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y... > We reduced our settings and finally reproduce it in a simple setup: > # configured a local cache (i.e. TestCache) with default settings > # a simple service bean ServiceA with a dummy method foo() annotated with @CacheResult(cacheName = 'TestCache'), which just return string "THIS_IS_RESULT_OF_FOO" > # a simple service bean ServiceB with a dummy method bar() which just return (ServiceA.foo() + "_PROCESSED_BY_BAR") > # a JCache CacheEntryCreatedListener which calling ServiceB.bar() and register to TestCache > When calling ServiceA.foo(), expecting ServiceA will generate a random string and got cached, then trigger the cache entry created listener to notify ServiceB to regenerate its value. > We also tested on latest stable version (10.1.8.Final) and still have such issue. We checked versions one by one and confirmed this bug introduced between change of 9.1.7 and 9.2.0. > [^ISPN-11942.zip] is a simple standalone application to reproduce this issue, change infinispan version from 10.1.8.Final to 9.1.7.Final will work correctly. Attached the trace log [^ISPN-11942-fail.log] when stay on 10.1.8.Final and [^ISPN-11942-success.log] when changed to 9.1.7.Final. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11918) org.infinispan.jcache.embedded.JCacheManager#create always throw CacheConfigurationException if create cache with template

by Sammy Chu (Jira)

[ https://issues.redhat.com/browse/ISPN-11918?page=com.atlassian.jira.plugi... ] Sammy Chu updated ISPN-11918: ----------------------------- Status: Open (was: New) > org.infinispan.jcache.embedded.JCacheManager#create always throw CacheConfigurationException if create cache with template > -------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-11918 > URL: https://issues.redhat.com/browse/ISPN-11918 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 10.1.8.Final > Reporter: Sammy Chu > Priority: Major > Attachments: ISPN-11918-fail.log, ISPN-11918-success.log, ISPN-11918.zip > > > Our project upgraded from Infinispan 8.2.4.Final to 9.4.18.Final and got `org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to define configuration for cache MY_CACHE_NAME which already exists` . > We are defining the cache template and then programmatically define the JCache with jcache configuration. From the source code of > [JCacheManager|https://github.com/infinispan/infinispan/blob/master/jcache...], it is reading the `baseConfig` as the template and then merge it with the jcache configuration, which is working expected in 8.2.4.Final. Now upgraded to 9.4.18.Final, it is not working due to change of ISPN-7540. > We checked this issue also reproducible on current latest stable release (10.1.8.Final). > [^ISPN-11918.zip] is a simple standalone application to reproduce this issue, change infinispan version from 10.1.8.Final to 8.2.12.Final will work correctly. Attached the trace log [^ISPN-11918-fail.log] when stay on 10.1.8.Final and [^ISPN-11918-success.log] when changed to 8.2.12.Final. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11176) XSite Max Idle

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugi... ] Paul Ferraro edited comment on ISPN-11176 at 8/8/20 11:36 AM: -------------------------------------------------------------- At the last F2F, while discussing locking w/x-site, I brought up the possibility of partitioning entries with a primary site (in the similar way that we partition them within a single cluster). With this in place, max-idle processing would be initiated only on the primary site for a given entry and cascaded to backup sites accordingly. It would, however, require that reads from the backup sites "touch" the primary site. Ideally, reads from a backup site would be rare - and only happen on failure of the primary site. For normal operation, this strategy has the advantage of minimal x-site traffic and simplifies max-idle processing by using a single authority for determining when to expire a given entry thereby preventing premature expirations. In the absence of this, however, option 1 seems like the better solution. was (Author: pferraro): At the last F2F, while discussing locking w/x-site, I brought up the possibility of partitioning entries with a primary site (in the similar way that we partition them within a single cluster). With this in place, max-idle processing would be initiated only on the primary site for a given entry and cascaded to backup sites accordingly. It would, however, require that reads from the backup sites "touch" the primary site. This strategy has the advantage of minimal x-site traffic (for non-exceptional cases) and simplifies max-idle processing by using a single authority for determining when to expire a given entry thereby preventing premature expirations. In the absence of this, however, option 1 seems like the better solution. > XSite Max Idle > -------------- > > Key: ISPN-11176 > URL: https://issues.redhat.com/browse/ISPN-11176 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication, Expiration > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > Max idle expiration currently doesn't work with xsite. That is if an entry was written and replicated to both sites but one site never reads the value, but the other does. If they then need to read the value from the other site it will be expired (assuming the max idle time has elapsed). > There are a few ways we can do this. > 1. Keep access times local to every site. When a site finds an entry is expired it asks the other site(s) if it has a more recent access. If a site is known to have gone down we should touch all entries, since they may not have updated access times. Requires very little additional xsite communication. > 2. Batch touch commands and only send every so often. Has window of loss, but should be small. Requires more site usage. Wouldn't work for really low max idle times as an entry could expire before the touch command is replicated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12206) Create an InfinispanXSiteServerRule and increase the tests coverage

by Gustavo Lira e Silva (Jira)

[ https://issues.redhat.com/browse/ISPN-12206?page=com.atlassian.jira.plugi... ] Gustavo Lira e Silva updated ISPN-12206: ---------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8614 > Create an InfinispanXSiteServerRule and increase the tests coverage > ------------------------------------------------------------------- > > Key: ISPN-12206 > URL: https://issues.redhat.com/browse/ISPN-12206 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 12.0.0.Dev01 > Reporter: Gustavo Lira e Silva > Assignee: Gustavo Lira e Silva > Priority: Major > > Create an InfinispanXSiteServerRule to replace [https://github.com/infinispan/infinispan/blob/master/server/test... is using one InfinispanServerRule for each site. > Increase the tests coverage -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12206) Create an InfinispanXSiteServerRule and increase the tests coverage

by Gustavo Lira e Silva (Jira)

Gustavo Lira e Silva created ISPN-12206: ------------------------------------------- Summary: Create an InfinispanXSiteServerRule and increase the tests coverage Key: ISPN-12206 URL: https://issues.redhat.com/browse/ISPN-12206 Project: Infinispan Issue Type: Enhancement Components: Test Suite Affects Versions: 12.0.0.Dev01 Reporter: Gustavo Lira e Silva Assignee: Gustavo Lira e Silva Create an InfinispanXSiteServerRule to replace [https://github.com/infinispan/infinispan/blob/master/server/test... is using one InfinispanServerRule for each site. Increase the tests coverage -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12206) Create an InfinispanXSiteServerRule and increase the tests coverage

by Gustavo Lira e Silva (Jira)

[ https://issues.redhat.com/browse/ISPN-12206?page=com.atlassian.jira.plugi... ] Gustavo Lira e Silva updated ISPN-12206: ---------------------------------------- Status: Open (was: New) > Create an InfinispanXSiteServerRule and increase the tests coverage > ------------------------------------------------------------------- > > Key: ISPN-12206 > URL: https://issues.redhat.com/browse/ISPN-12206 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 12.0.0.Dev01 > Reporter: Gustavo Lira e Silva > Assignee: Gustavo Lira e Silva > Priority: Major > > Create an InfinispanXSiteServerRule to replace [https://github.com/infinispan/infinispan/blob/master/server/test... is using one InfinispanServerRule for each site. > Increase the tests coverage -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8388) Entity with @Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE) fails if cache is configured as simple cache

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/ISPN-8388?page=com.atlassian.jira.plugin... ] Paul Ferraro updated ISPN-8388: ------------------------------- Affects Version/s: 11.0.3.Final 10.1.8.Final 9.4.20.Final (was: 9.1.1.Final) (was: 9.2.0.Alpha1) > Entity with @Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE) fails if cache is configured as simple cache > -------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-8388 > URL: https://issues.redhat.com/browse/ISPN-8388 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.4.20.Final, 10.1.8.Final, 11.0.3.Final > Reporter: Paul Ferraro > Priority: Critical > > The Infinispan region factory needs to explicitly disable the simple cache optimization for cache regions that will use the NONSTRICT_READ_WRITE concurrency strategy. > This issue is particularly troublesome for WildFly where the simple cache optimization is automatically enabled for non-transactional, non-persistent local caches. > {noformat} > 2017-10-06 14:56:36,221 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.persistenceunit."harmonyserver.sar#IpsDb": org.jboss.msc.service.StartException in service jboss.persistenceunit."harmonyserver.sar#IpsDb": javax.persistence.PersistenceException: [PersistenceUnit: IpsDb] Unable to build Hibernate SessionFactory > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:179) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:121) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:193) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: IpsDb] Unable to build Hibernate SessionFactory > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882) > at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:161) > ... 7 more > Caused by: java.lang.UnsupportedOperationException: ISPN000376: Interceptor stack is not supported in simple cache > at org.infinispan.cache.impl.SimpleCacheImpl.removeInterceptor(SimpleCacheImpl.java:952) > at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.removeInterceptor(AbstractDelegatingAdvancedCache.java:85) > at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForVersionedEntries(BaseTransactionalDataRegion.java:154) > at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:122) > at org.hibernate.cache.infinispan.entity.EntityRegionImpl.buildAccessStrategy(EntityRegionImpl.java:50) > at org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:624) > at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:332) > at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879) > ... 9 more > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2020