March 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11507) Split JDK-specific classes into separate modules

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11507?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11507: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8081 > Split JDK-specific classes into separate modules > ------------------------------------------------ > > Key: ISPN-11507 > URL: https://issues.redhat.com/browse/ISPN-11507 > Project: Infinispan > Issue Type: Enhancement > Components: Build, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Dev04 > > > The current build uses different source folders for each JDK, but IDEs don't really work well since we require different version support per source folder. > We need to split each JDK-specific into a dedicated maven module -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11507) Split JDK-specific classes into separate modules

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11507?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11507: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Split JDK-specific classes into separate modules > ------------------------------------------------ > > Key: ISPN-11507 > URL: https://issues.redhat.com/browse/ISPN-11507 > Project: Infinispan > Issue Type: Enhancement > Components: Build, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Dev04 > > > The current build uses different source folders for each JDK, but IDEs don't really work well since we require different version support per source folder. > We need to split each JDK-specific into a dedicated maven module -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11399) BasicComponentRegistryImpl can block when starting a component

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11399?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11399: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > BasicComponentRegistryImpl can block when starting a component > -------------------------------------------------------------- > > Key: ISPN-11399 > URL: https://issues.redhat.com/browse/ISPN-11399 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04 > > > The following stack trace can be seen sometimes while starting a cache > {code} > java.lang.AssertionError: Blocking call! jdk.internal.misc.Unsafe#park on thread Thread[non-blocking-thread-ClusterTopologyManagerTest-NodeA-p35892-t1,5,main] > at org.infinispan.util.CoreTestBlockHoundIntegration.lambda$applyTo$0(CoreTestBlockHoundIntegration.java:37) > 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.acquireQueued(AbstractQueuedSynchronizer.java:917) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240) > at java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.logStartedComponent(BasicComponentRegistryImpl.java:591) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.doStartWrapper(BasicComponentRegistryImpl.java:576) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:547) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.access$700(BasicComponentRegistryImpl.java:30) > at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:770) > at org.infinispan.factories.GlobalComponentRegistry.getLocalTopologyManager(GlobalComponentRegistry.java:378) > at org.infinispan.commands.topology.CacheStatusRequestCommand.invokeAsync(CacheStatusRequestCommand.java:34) > at org.infinispan.topology.TopologyManagementHelper.invokeAsync(TopologyManagementHelper.java:152) > at org.infinispan.topology.TopologyManagementHelper.executeOnClusterSync(TopologyManagementHelper.java:52) > at org.infinispan.topology.ClusterTopologyManagerImpl.fetchClusterStatus(ClusterTopologyManagerImpl.java:545) > at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:417) > at org.infinispan.topology.ClusterTopologyManagerImpl.lambda$handleClusterView$4(ClusterTopologyManagerImpl.java:382) > at org.infinispan.util.concurrent.ActionSequencer.safeNonBlockingCall(ActionSequencer.java:47) > at org.infinispan.util.concurrent.ActionSequencer.access$200(ActionSequencer.java:28) > at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.apply(ActionSequencer.java:162) > at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.apply(ActionSequencer.java:128) > at java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907) > 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)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11515) Drop use of java.security.acl.Group

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11515?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11515: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8083, https://github.com/infinispan/infinispan/pull/8084 > Drop use of java.security.acl.Group > ----------------------------------- > > Key: ISPN-11515 > URL: https://issues.redhat.com/browse/ISPN-11515 > Project: Infinispan > Issue Type: Task > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Dev04, 10.1.6.Final > > > java.security.acl.Group was deprecated in Java 9 and will be removed in Java 15. We should remove its use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11515) Drop use of java.security.acl.Group

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11515?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11515: ----------------------------------- Status: Open (was: New) > Drop use of java.security.acl.Group > ----------------------------------- > > Key: ISPN-11515 > URL: https://issues.redhat.com/browse/ISPN-11515 > Project: Infinispan > Issue Type: Task > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Dev04, 10.1.6.Final > > > java.security.acl.Group was deprecated in Java 9 and will be removed in Java 15. We should remove its use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11515) Drop use of java.security.acl.Group

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-11515: -------------------------------------- Summary: Drop use of java.security.acl.Group Key: ISPN-11515 URL: https://issues.redhat.com/browse/ISPN-11515 Project: Infinispan Issue Type: Task Affects Versions: 11.0.0.Dev03, 10.1.5.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 11.0.0.Dev04, 10.1.6.Final java.security.acl.Group was deprecated in Java 9 and will be removed in Java 15. We should remove its use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11514) CacheMgmtInterceptor getNumberOfEntries should include expired entries

by Dan Berindei (Jira)

Dan Berindei created ISPN-11514: ----------------------------------- Summary: CacheMgmtInterceptor getNumberOfEntries should include expired entries Key: ISPN-11514 URL: https://issues.redhat.com/browse/ISPN-11514 Project: Infinispan Issue Type: Feature Request Components: API, Core Affects Versions: 11.0.0.Dev03 Reporter: Dan Berindei Fix For: 11.0.0.Final {{CacheMgmtInterceptor.getNumberOfEntries}} and {{CacheMgmtInterceptor.getNumberOfEntriesInMemory}} both require an iteration over the data container and/or stores in order to exclude expired entries. Since these are statistics, they don't have to be exact, so we can include expired entries until a read or the expiration reaper removes them from the cache. In fact, I would argue that it's more correct for {{CacheMgmtInterceptor.getNumberOfEntriesInMemory}} to include expired entries, because expired entries still use memory until they are removed. The most likely reason that the strategy for counting entries was changed with ISPN-7686 is that the {{AdvancedCache}} doesn't have a {{sizeIncludingExpired}} method. Since it's not possible to obtain the exact size of the cache with passivation enabled without iterating over the store to eliminate duplicates, I suggest instead to estimate {{CacheMgmtInterceptor.getNumberOfEntries}} as the number of entries in the data container + the number of entries in the store. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11513) ComposedSegmentedLoadWriteStore should not iterate over segments in parallel

by Dan Berindei (Jira)

Dan Berindei created ISPN-11513: ----------------------------------- Summary: ComposedSegmentedLoadWriteStore should not iterate over segments in parallel Key: ISPN-11513 URL: https://issues.redhat.com/browse/ISPN-11513 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 11.0.0.Dev03, 10.1.5.Final Reporter: Dan Berindei Assignee: Will Burns Fix For: 11.0.0.Final {{ComposedSegmentedLoadWriteStore}} always parallelizes iterations, even when the consumer is a single thread doing a blocking iteration like {{cache.keySet().forEach(...)}}. This will use lots of blocking threads, and will crowd out single-key cache operations, which are more sensitive to latency (because there are usually multiple single-key operations for each user request). It would be interesting to extend the persistence SPI so that the store knows when the user requested parallel iteration, but in the meantime it's safer to iterate over the segments in sequence. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11511) Custom branding creates ambiguous logs on server startup

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11511?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11511: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8082 > Custom branding creates ambiguous logs on server startup > -------------------------------------------------------- > > Key: ISPN-11511 > URL: https://issues.redhat.com/browse/ISPN-11511 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Pavel Drobek > Assignee: Tristan Tarrant > Priority: Major > > Server starts up with following message in the logs: > {code} > INFO (main) [org.infinispan.SERVER] ISPN080001: Red Hat Data Grid Server 10.1.5.Final-redhat-00001 started in 4708ms > {code} > Expected message: > {code} > INFO (main) [org.infinispan.SERVER] ISPN080001: Red Hat Data Grid Server 8.0.0.GA started in 4708ms > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11512) The mass indexer should iterate over the cache only once

by Dan Berindei (Jira)

Dan Berindei created ISPN-11512: ----------------------------------- Summary: The mass indexer should iterate over the cache only once Key: ISPN-11512 URL: https://issues.redhat.com/browse/ISPN-11512 Project: Infinispan Issue Type: Enhancement Components: Indexing Affects Versions: 11.0.0.Dev03, 10.1.5.Final Reporter: Dan Berindei Assignee: Gustavo Fernandes Fix For: 11.0.0.Final {{DistributedExecutorMassIndexer}} starts an {{IndexWorker}} for each indexed type and submits them to all the nodes in parallel. Each {{IndexWorker}} runs a blocking iteration over the cache, and when the cache has a store, that iteration is very expensive. Each iteration will load and deserialize all the entries in the store. Most stores don't implement {{AbstractSegmentedStoreConfiguration}}, so Infinispan wraps them in a {{ComposedSegmentedLoadWriteStore}}, which iterates over each segment in parallel on the persistence/blocking executor. Since the default number of segments is 256 and the persistence/blocking executor has 4*cpu_count/150 max threads, it doesn't take a lot of parallel iterations to fill the blocking executor's threads and prevent the cache from doing other, more urgent, work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2020