June 2019 - infinispan-issues - Jboss List Archives

[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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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)

5 years, 6 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: ------------------------------- Summary: Distribution zips are not properly installed (was: Distribution zip are not properly installed) > 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)

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