May 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (HRJS-86) Don't expose log4js dependency

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/HRJS-86?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated HRJS-86: --------------------------------- Labels: rhdemo-2019 (was: ) > Don't expose log4js dependency > ------------------------------ > > Key: HRJS-86 > URL: https://issues.jboss.org/browse/HRJS-86 > Project: Infinispan Javascript client > Issue Type: Enhancement > Reporter: Galder Zamarreño > Priority: Major > Labels: rhdemo-2019 > > Do not require users to set/depend on log4js, instead hide it behind our own API. > See Evan's comments in [this issue|https://github.com/rhdemo/2019-demo4-web-game/pull/40]. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HRJS-86) Don't expose log4js dependency

by Galder Zamarreño (Jira)

Galder Zamarreño created HRJS-86: ------------------------------------ Summary: Don't expose log4js dependency Key: HRJS-86 URL: https://issues.jboss.org/browse/HRJS-86 Project: Infinispan Javascript client Issue Type: Enhancement Reporter: Galder Zamarreño Do not require users to set/depend on log4js, instead hide it behind our own API. See Evan's comments in [this issue|https://github.com/rhdemo/2019-demo4-web-game/pull/40]. -- 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 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, 11 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10149) Enable checkstyle plugin during the verify maven phase

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10149?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10149: ----------------------------------- Fix Version/s: 9.4.14.Final (was: 9.4.13.Final) > Enable checkstyle plugin during the verify maven phase > ------------------------------------------------------ > > Key: ISPN-10149 > URL: https://issues.jboss.org/browse/ISPN-10149 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.12.Final, 10.0.0.Beta3 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 10.0.0.Beta4, 9.4.14.Final > > > Today the checkstyle configuration is duplicated across multiple projects > The docs say > {noformat} > ===== Checking coding style > If you have written any new code, it is highly recommended to validate formatting before submitting a Pull Request. > This might be done by invoking: > $ mvn checktyle:check > {noformat} > but it is failing > {noformat} > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 7.296 s > [INFO] Finished at: 2019-04-25T19:55:17-03:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] No plugin found for prefix 'checktyle' in the current project and in the plugin groups [com.oracle.weblogic, org.jenkins-ci.tools, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/dlovison/.m2/repository), -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixEx... > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

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