April 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11543) Add BlockingHandler to simplify running blocking operations

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11543?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11543: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add BlockingHandler to simplify running blocking operations > ----------------------------------------------------------- > > Key: ISPN-11543 > URL: https://issues.redhat.com/browse/ISPN-11543 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev05 > > > We have quite a few places that must run blocking operations that cannot be changed. These places must run the operation in a blocking thread and return on a non blocking thread. All of these places must register both a blocking and non blocking thread pool and properly handle them. This is both error prone and a lot of extra code. We should isolate this to a shared component which will in turn provide for an easier way to find such operations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11524) PersistenceManagerImpl locks should be able to block

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11524?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11524: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 11.0.0.Dev05 Resolution: Done > PersistenceManagerImpl locks should be able to block > ---------------------------------------------------- > > Key: ISPN-11524 > URL: https://issues.redhat.com/browse/ISPN-11524 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Dev05 > > > Here is an example stack trace acquired > {code} > java.lang.AssertionError: Blocking call! jdk.internal.misc.Unsafe#park on thread Thread[non-blocking-thread-SharedStoreTest-NodeB-p19754-t5,5,main] > at org.infinispan.util.CoreTestBlockHoundIntegration.lambda$applyTo$0(CoreTestBlockHoundIntegration.java:43) > at reactor.blockhound.BlockHound$Builder.lambda$install$6(BlockHound.java:318) > at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:46) > at java.base/jdk.internal.misc.Unsafe.park(Unsafe.java) > at java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:1009) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1324) > at java.base/java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:738) > at org.infinispan.persistence.manager.PersistenceManagerImpl.getFirstSegmentedStore(PersistenceManagerImpl.java:665) > at org.infinispan.persistence.manager.PersistenceManagerImpl.publishEntries(PersistenceManagerImpl.java:704) > at org.infinispan.persistence.manager.PersistenceManagerImpl.publishEntries(PersistenceManagerImpl.java:121) > at org.infinispan.statetransfer.StateProviderImpl.publishStoreEntries(StateProviderImpl.java:307) > at org.infinispan.scattered.impl.ScatteredStateProviderImpl.replicateAndInvalidate(ScatteredStateProviderImpl.java:94) > at org.infinispan.scattered.impl.ScatteredStateProviderImpl.onTopologyUpdate(ScatteredStateProviderImpl.java:53) > at org.infinispan.statetransfer.StateTransferManagerImpl.updateProviderAndConsumer(StateTransferManagerImpl.java:202) > at org.infinispan.statetransfer.StateTransferManagerImpl.lambda$doTopologyUpdate$0(StateTransferManagerImpl.java:188) > at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) > at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) > at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:143) > at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:187) > at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:66) > at org.infinispan.statetransfer.StateTransferManagerImpl$1.rebalance(StateTransferManagerImpl.java:124) > at org.infinispan.topology.LocalTopologyManagerImpl.lambda$doHandleRebalance$19(LocalTopologyManagerImpl.java:578) > at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072) > at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610) > at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:840) > at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11703) JGroups Stacks should be initialized lazily

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11703?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11703: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Will Burns Resolution: Done > JGroups Stacks should be initialized lazily > ------------------------------------------- > > Key: ISPN-11703 > URL: https://issues.redhat.com/browse/ISPN-11703 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev05 > > > When we initialize the Parser we always read in the default jgroups stacks. This is done even if the global configuration doesn't have clustering. The parser is also started whenever a new cache is configured and started at runtime. These should be done only if the parser requires the jgroups stacks. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11729) REST endpoint to handle rebalancing per cache

by Katia Aresti (Jira)

Katia Aresti created ISPN-11729: ----------------------------------- Summary: REST endpoint to handle rebalancing per cache Key: ISPN-11729 URL: https://issues.redhat.com/browse/ISPN-11729 Project: Infinispan Issue Type: Feature Request Components: REST Affects Versions: 10.1.6.Final Reporter: Katia Aresti Assignee: Tristan Tarrant Add a Rest endpoint to the CacheV2Resource to enable/disable rebalancing for a cache -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11728) REST endpoint to handle rebalancing at cluster level

by Katia Aresti (Jira)

Katia Aresti created ISPN-11728: ----------------------------------- Summary: REST endpoint to handle rebalancing at cluster level Key: ISPN-11728 URL: https://issues.redhat.com/browse/ISPN-11728 Project: Infinispan Issue Type: Feature Request Components: REST Affects Versions: 10.1.6.Final Reporter: Katia Aresti Assignee: Tristan Tarrant Add a REST endpoint in the CacheManagerResource to enable and disable rebalancing at cache manager level -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11503) Export Rolling Upgrade operations via REST

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11503?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11503: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.1.7.Final Resolution: Done > Export Rolling Upgrade operations via REST > ------------------------------------------ > > Key: ISPN-11503 > URL: https://issues.redhat.com/browse/ISPN-11503 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.Alpha2, 10.1.5.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Final, 10.1.7.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11727) Async Cache Writer is blocking

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11727?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11727: ------------------------------ Description: The current AsyncCacheWriter is blocking on a few different levels. It first has a lock to add a modification to its queue, which is able to be configured by the end user. It may even be possible to configure a value so low that if a bulkUpdate is done that is larger than the configured value it may hang (needs to be confirmed). However this lock can and will block if an async update takes too long and the queue is full of writes. We should at least return a future that is complete when the value is written to the queue instead. We may want to even use something like https://github.com/IBM/java-async-util with their AsyncSemaphore to handle this queueing in a non blocking way. This however will require https://issues.redhat.com/browse/ISPN-10373 to be implemented first, before it can be made fully non blocking. was: The current AsyncCacheWriter is blocking on a few different levels. It first has a lock to add a modification to its queue, which is able to be configured by the end user. It may even be possible to configure a value so low that if a bulkUpdate is done that is larger than the configured value it may hang (needs to be confirmed). However this lock can and will block if an async update takes too long and the queue is full of writes. We should at least return a future that is complete when the value is written to the queue instead. We may want to even use something like https://github.com/IBM/java-async-util with their AsyncSemaphore to handle this queueing in a non blocking way. > Async Cache Writer is blocking > ------------------------------ > > Key: ISPN-11727 > URL: https://issues.redhat.com/browse/ISPN-11727 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Will Burns > Priority: Major > > The current AsyncCacheWriter is blocking on a few different levels. > It first has a lock to add a modification to its queue, which is able to be configured by the end user. It may even be possible to configure a value so low that if a bulkUpdate is done that is larger than the configured value it may hang (needs to be confirmed). > However this lock can and will block if an async update takes too long and the queue is full of writes. We should at least return a future that is complete when the value is written to the queue instead. > We may want to even use something like https://github.com/IBM/java-async-util with their AsyncSemaphore to handle this queueing in a non blocking way. This however will require https://issues.redhat.com/browse/ISPN-10373 to be implemented first, before it can be made fully non blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11727) Async Cache Writer is blocking

by Will Burns (Jira)

Will Burns created ISPN-11727: --------------------------------- Summary: Async Cache Writer is blocking Key: ISPN-11727 URL: https://issues.redhat.com/browse/ISPN-11727 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Will Burns The current AsyncCacheWriter is blocking on a few different levels. It first has a lock to add a modification to its queue, which is able to be configured by the end user. It may even be possible to configure a value so low that if a bulkUpdate is done that is larger than the configured value it may hang (needs to be confirmed). However this lock can and will block if an async update takes too long and the queue is full of writes. We should at least return a future that is complete when the value is written to the queue instead. We may want to even use something like https://github.com/IBM/java-async-util with their AsyncSemaphore to handle this queueing in a non blocking way. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11726) BlockingLocalTopologyManager is blocking - ignore in BlockHound

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11726?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11726: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8247 > BlockingLocalTopologyManager is blocking - ignore in BlockHound > --------------------------------------------------------------- > > Key: ISPN-11726 > URL: https://issues.redhat.com/browse/ISPN-11726 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev05 > > > BlockingLocalTopologyManager blocks all over to confirm things during tests. We should add blockhound exclusions for it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11726) BlockingLocalTopologyManager is blocking - ignore in BlockHound

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11726?page=com.atlassian.jira.plugi... ] Work on ISPN-11726 started by Will Burns. ----------------------------------------- > BlockingLocalTopologyManager is blocking - ignore in BlockHound > --------------------------------------------------------------- > > Key: ISPN-11726 > URL: https://issues.redhat.com/browse/ISPN-11726 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev05 > > > BlockingLocalTopologyManager blocks all over to confirm things during tests. We should add blockhound exclusions for it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 April 2020