May 2019 - infinispan-issues - Jboss List Archives

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

by Rens van Leeuwen (Jira)

[ https://issues.jboss.org/browse/ISPN-10171?page=com.atlassian.jira.plugin... ] Rens van Leeuwen updated ISPN-10171: ------------------------------------ Git Pull Request: 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 > 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, 5 months

1
0
0 / 0

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

by Rens van Leeuwen (Jira)

Rens van Leeuwen created ISPN-10171: --------------------------------------- Summary: 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 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10142) Wildfly modules integrationtests ignore branding

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10142?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10142: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Wildfly modules integrationtests ignore branding > ------------------------------------------------ > > Key: ISPN-10142 > URL: https://issues.jboss.org/browse/ISPN-10142 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.4.12.Final, 10.0.0.Beta3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_failure > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > {{standalone-test.xml}} uses module {{org.infinispan.extension:ispn-${infinispan.core.schema.version}}}, ignoring the branding. The module name should be {{org.infinispan.extension:${infinispan.module.slot}}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9852) Invocations waiting for a new topology should resume in parallel

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9852?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9852: ---------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Invocations waiting for a new topology should resume in parallel > ---------------------------------------------------------------- > > Key: ISPN-9852 > URL: https://issues.jboss.org/browse/ISPN-9852 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.11.Final, 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > When a command requires a topology newer than the current topology, it uses {{StateTransferLock.transactionDataFuture()}} to wait for the newer topology. When the tx data is received for the newer topology, some (most?) of the waiting operations do not use a separate executor, instead they are all resumed on the thread that received the tx data. If some operations block (e.g. because of a store), it could take a very long time to finish all the blocked operations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10029) Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10029?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10029: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK > --------------------------------------------------------------------------------------------------- > > Key: ISPN-10029 > URL: https://issues.jboss.org/browse/ISPN-10029 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.11.Final, 10.0.0.Beta3 > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 10.0.0.Beta4, 9.3.7.Final, 9.4.14.Final > > Attachments: InvalidationLockingTest.java > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10040: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Embedded and server thread pool defaults should be the same > ----------------------------------------------------------- > > Key: ISPN-10040 > URL: https://issues.jboss.org/browse/ISPN-10040 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 8.2.11.Final, 9.4.9.Final, 10.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > Embedded: > {code:java} > DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200); > DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0); > {code} > Server: > {code:java} > REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000), > {code} > Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10062) Docs refer to infinispan-cli-server instead of infinispan-cli-interpreter

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10062?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10062: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Docs refer to infinispan-cli-server instead of infinispan-cli-interpreter > ------------------------------------------------------------------------- > > Key: ISPN-10062 > URL: https://issues.jboss.org/browse/ISPN-10062 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Core > Affects Versions: 9.4.10.Final, 10.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10070) DefaultCacheManager should stop components after start failure

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10070: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > DefaultCacheManager should stop components after start failure > -------------------------------------------------------------- > > Key: ISPN-10070 > URL: https://issues.jboss.org/browse/ISPN-10070 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.10.Final, 10.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > Currently it is impossible to release all the resources allocated during startup if the {{DefaultCacheManager}} instance was created with {{start=true}}. The user has to do something like this: > {code:java} > DefaultCacheManager manager = new DefaultCacheManager(..., false); > try { > manager.start(); > } catch (Throwable t) { > manager.stop(); > throw t; > } > {code} > Both the constructor and the public {{start()}} method should clean up the started components after a startup failure, so that the user doesn't have to call {{stop()}} explicitly. > Our tests do not currently call {{stop()}} explicitly, so they leak threads and sockets when a manager fails to start (e.g. because something went wrong with the {{CONFIG}} cache). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10074) DefaultSegmentedDataContainer executeTask() and iterator() include expired entries

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10074?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10074: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > DefaultSegmentedDataContainer executeTask() and iterator() include expired entries > ---------------------------------------------------------------------------------- > > Key: ISPN-10074 > URL: https://issues.jboss.org/browse/ISPN-10074 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.10.Final, 10.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > The {{executeTask()}} javadoc doesn't mention expired entries, but {{iterator()}}'s says they shouldn't be included, and non-segmented containers do not include them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10080) Test cache managers created in other threads cannot join the UDP cluster

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10080?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10080: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Test cache managers created in other threads cannot join the UDP cluster > ------------------------------------------------------------------------ > > Key: ISPN-10080 > URL: https://issues.jboss.org/browse/ISPN-10080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.4.11.Final, 10.0.0.Beta3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > When a test wants to create a cache manager in another thread (e.g. with {{fork()}}) it should be able to call {{TestResourceTracker.testThreadStarted(this)}} and join the same cluster. > That works with TCP, but with UDP each thread gets its own multicast address and port, so multicast messages from one node don't reach the other. Unicast messages and {{TEST_PING}} do work. > This is the issue that made {{FunctionalTxTest}} fail in https://github.com/infinispan/infinispan/pull/6442 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2019