June 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10309) Convert Remaining Parts to Non Blocking & Reduce Thread Pools

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10309?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10309: ------------------------------ Sprint: DataGrid Sprint #29, DataGrid Sprint #30 (was: DataGrid Sprint #29) > Convert Remaining Parts to Non Blocking & Reduce Thread Pools > ------------------------------------------------------------- > > Key: ISPN-10309 > URL: https://issues.jboss.org/browse/ISPN-10309 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Final > > > We would love to get our thread pools down to a single CPU thread pool (size = numCores) and a blocking thread pool (arbitrarily large). We may also require a scheduler pool for various options as well (limited size 1-2?). > To do this we need to remove remnants of our blocking code as possible. Possible issues for blocking are mostly around locks and io operations. > The persistence layer was completed with ISPN-9722 so that is not an issue. > The requirement around locking can be relaxed if the locks are guaranteed to be small in scope and do not wrap other blocking operations. An example would be a lock such as ones in CHM as long as we don't have large blocks for functional argument types. > If code cannot be made non blocking we must offload the operation to the blocking thread pool. Care must be taken to ensure that once the blocking portion of code is completed that we switch back the to CPU thread pool as soon as possible. The listener API for example is violating this and will run code in Infinispan from any thread that completes the listener that could be done from a user. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5241) Cache topology updates should use the NO_FC flag

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-5241?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-5241. -------------------------------- Resolution: Out of Date We have replaced MFC with MFC_NB, which almost never blocks. > Cache topology updates should use the NO_FC flag > ------------------------------------------------ > > Key: ISPN-5241 > URL: https://issues.jboss.org/browse/ISPN-5241 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 10.0.0.Final > > > Topology updates are sent while holding the ClusterCacheStatus lock, so they should never block. However, when MFC is present, the topology update can block waiting for enough credits. As most CacheTopologyControlCommands need to acquire the ClusterCacheStatus lock, this can easily lead to a full remote-executor pool (and OOB pool) and the appearance of a deadlock. > What's more, if one node is not responsive, it can block all the other nodes from receiving further topology updates. Topology updates should be as prompt as possible, so we should use the NO_FC flag to ensure that each node receives topology updates as soon as possible. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5557) Core threading redesign

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-5557?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5557: ---------------------------------- Assignee: Will Burns (was: Dan Berindei) > Core threading redesign > ----------------------- > > Key: ISPN-5557 > URL: https://issues.jboss.org/browse/ISPN-5557 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.2.Final > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Critical > Fix For: 10.0.0.Final > > > Infinispan needs a lot of threads, because everything is synchronous: locking, remote command invocations, cache writers. This causes various issues, from general context switching overhead to the thread pools getting full and causing deadlocks. > We should redesign the core so that most blocking happens on the application threads, and the number of internal threads is kept to a minimum. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6094) Use security actions to read system properties for configuration

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-6094?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-6094. -------------------------------- Fix Version/s: 7.0.0.Final (was: 10.0.0.Final) Resolution: Done The security actions were introduced with ISPN-3931 > Use security actions to read system properties for configuration > ---------------------------------------------------------------- > > Key: ISPN-6094 > URL: https://issues.jboss.org/browse/ISPN-6094 > Project: Infinispan > Issue Type: Task > Components: Core, Embedded Querying > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 7.0.0.Final > > > Infinispan uses system properties for out-of-band settings that weren't deemed important enough to have a proper configuration attribute: > * infinispan.arrays.debug > * infinispan.unsafe.force_multicast > * infinispan.compat (obsolete?) > * infinispan.debugDependencies > * infinispan.stagger.delay (introduced with ISPN-825) > * org.infinispan.query.indexmanager.LockAcquiringBackend.MAX_QUEUE_SIZE > We should use a {{SecurityActions}} class to access these properties instead of {{Boolean.getBoolean()}} and {{Integer.getInteger()}}. We should also document these system properties, and evaluate moving them to the proper configuration. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6309) Preload does not work with invalidation cache [file-store]

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-6309?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-6309. -------------------------------- Fix Version/s: 9.0.0.Final Resolution: Out of Date Can't happen since ISPN-7400, the topology is always non-null > Preload does not work with invalidation cache [file-store] > ---------------------------------------------------------- > > Key: ISPN-6309 > URL: https://issues.jboss.org/browse/ISPN-6309 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.1.0.Final > Reporter: Goran Jaric > Assignee: Dan Berindei > Priority: Critical > Fix For: 9.0.0.Final > > Attachments: CacheException.log, infinispan.xml, jgroups-tcp.xml > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6479) CacheRpcCommandExternalizer should cache the cache name bytes

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-6479?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-6479. -------------------------------- Fix Version/s: 9.0.0.Final (was: 10.0.0.Final) Resolution: Done Fixed with ISPN-6488 > CacheRpcCommandExternalizer should cache the cache name bytes > ------------------------------------------------------------- > > Key: ISPN-6479 > URL: https://issues.jboss.org/browse/ISPN-6479 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9907) NullPointerException when async operations share a LocalTransaction

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9907?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-9907. -------------------------------- Fix Version/s: 9.4.16.Final Assignee: Dan Berindei Resolution: Done Fixed with ISPN-10239 in 9.4.x and fixed by removing atomic maps in 10.x > NullPointerException when async operations share a LocalTransaction > ------------------------------------------------------------------- > > Key: ISPN-9907 > URL: https://issues.jboss.org/browse/ISPN-9907 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.Alpha3, 9.4.6.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 9.4.16.Final > > Attachments: ISPN-4075_timestamps_improvements_20190128-1450_DistFineGrainedAtomicMapAPITest-infinispan-core.log.gz > > > I'm not convinced we should support invoking multiple cache operations bound to the same TM transaction in parallel, but {{FineGrainedAtomicMapProxyImpl.removeAll()}} calls {{AdvancedCache.removeAsync()}} for each key in the map and then blocks to wait for all of them. > Because the {{lookedUpEntries}} map in {{LocalTransaction}} is not synchronized, this makes {{DistFineGrainedAtomicMapAPITest}} fail randomly with a {{NullPointerException}}: > {noformat} > 15:05:36,898 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.atomic.DistFineGrainedAtomicMapAPITest.testReplicationPutAndClearCommit > java.lang.NullPointerException: null > at org.infinispan.interceptors.impl.CallInterceptor.visitRemoveCommand(CallInterceptor.java:238) ~[classes/:?] > at org.infinispan.interceptors.impl.CallInterceptor.visitRemoveCommand(CallInterceptor.java:226) ~[classes/:?] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51) ~[classes/:?] > at org.infinispan.interceptors.impl.CallInterceptor.visitCommand(CallInterceptor.java:160) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:152) ~[classes/:?] > at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:427) ~[classes/:?] > at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:138) ~[classes/:?] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:98) ~[classes/:?] > at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:671) ~[classes/:?] > at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:356) ~[classes/:?] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitRemoveCommand(DDAsyncInterceptor.java:64) ~[classes/:?] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitRemoveCommand(DDAsyncInterceptor.java:64) ~[classes/:?] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lambda$new$0(AbstractTxLockingInterceptor.java:34) ~[classes/:?] > at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25) ~[classes/:?] > at org.infinispan.interceptors.SyncInvocationStage.addCallback(SyncInvocationStage.java:42) ~[classes/:?] > at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45) ~[classes/:?] > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireLocalLockAndInvokeNext(PessimisticLockingInterceptor.java:283) ~[classes/:?] > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$visitDataWriteCommand$3(PessimisticLockingInterceptor.java:154) ~[classes/:?] > at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25) ~[classes/:?] > at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:118) ~[classes/:?] > at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81) ~[classes/:?] > at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30) ~[classes/:?] > at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760) ~[?:1.8.0_171] > at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736) ~[?:1.8.0_171] > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) ~[?:1.8.0_171] > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) ~[?:1.8.0_171] > at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67) ~[classes/:?] > at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102) ~[classes/:?] > at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52) ~[classes/:?] > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1372) ~[classes/:?] > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1275) ~[classes/:?] > Suppressed: org.infinispan.util.logging.TraceException > at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:41) ~[classes/:?] > at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:138) ~[classes/:?] > at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81) ~[classes/:?] > at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30) ~[classes/:?] > at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760) ~[?:1.8.0_171] > at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736) ~[?:1.8.0_171] > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) ~[?:1.8.0_171] > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) ~[?:1.8.0_171] > at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67) ~[classes/:?] > at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102) ~[classes/:?] > at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52) ~[classes/:?] > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1372) ~[classes/:?] > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1275) ~[classes/:?] > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6485) JGroupsTransport.lambda$invokeRemotelyAsync$1 seems to trigger resizes of HashMap

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-6485?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6485: ------------------------------- Sprint: DataGrid Sprint #30 > JGroupsTransport.lambda$invokeRemotelyAsync$1 seems to trigger resizes of HashMap > --------------------------------------------------------------------------------- > > Key: ISPN-6485 > URL: https://issues.jboss.org/browse/ISPN-6485 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne GRINOVERO > Assignee: Dan Berindei > Priority: Minor > > The resize of an {{HashMap}} is highlighted by the JFR profiler in this method, it's possible that this is very simple to fix by simply creating the Map with a better estimate. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10361) Distribution zips are not properly installed

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10361?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10361: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7095 > Distribution zips are not properly installed > -------------------------------------------- > > Key: ISPN-10361 > URL: https://issues.jboss.org/browse/ISPN-10361 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 10.0.0.Beta3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta4 > > > The {{maven-assembly-plugin}} uses the {{assemblyId}} as a classifier when installing/deploying the zip files. > Since it was disabled for {{server}}, {{wildfly-server}}, and {{modules}}, maven installs all 3 zips with the same name. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10361) Distribution zips are not properly installed

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10361?page=com.atlassian.jira.plugin... ] Work on ISPN-10361 started by Pedro Ruivo. ------------------------------------------ > Distribution zips are not properly installed > -------------------------------------------- > > Key: ISPN-10361 > URL: https://issues.jboss.org/browse/ISPN-10361 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 10.0.0.Beta3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta4 > > > The {{maven-assembly-plugin}} uses the {{assemblyId}} as a classifier when installing/deploying the zip files. > Since it was disabled for {{server}}, {{wildfly-server}}, and {{modules}}, maven installs all 3 zips with the same name. -- 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 June 2019