March 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10270) DroppedConnectionsTest.testClosedConnection random failures

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-10270?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-10270: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > DroppedConnectionsTest.testClosedConnection random failures > ----------------------------------------------------------- > > Key: ISPN-10270 > URL: https://issues.redhat.com/browse/ISPN-10270 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Beta3 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Priority: Major > Labels: testsuite_stability > Fix For: 11.0.0.Dev04, 10.1.6.Final > > Attachments: ISPN-10137_Injection_without_reflection_20190605-1157_DroppedConnectionsTest-infinispan-client-hotrod.log.gz > > > {noformat} > 12:03:26,084 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.DroppedConnectionsTest.testClosedConnection > java.lang.AssertionError: expected:<1> but was:<0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.14.3.jar:?] > at org.infinispan.client.hotrod.DroppedConnectionsTest.testClosedConnection(DroppedConnectionsTest.java:78) ~[test-classes/:?] > {noformat} > Full trace log attached -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11205) DataSource support in the Server

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11205?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11205: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > DataSource support in the Server > -------------------------------- > > Key: ISPN-11205 > URL: https://issues.redhat.com/browse/ISPN-11205 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 10.1.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Dev04, 11.0.0.Final > > > The server needs to have the ability to manage datasources/connection pools to databases so that they can be shared by multiple cache stores/loaders. > We should use Agroal for this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11126) Health check fails when authz is enabled and cache is not yet started

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11126?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11126: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > Health check fails when authz is enabled and cache is not yet started > --------------------------------------------------------------------- > > Key: ISPN-11126 > URL: https://issues.redhat.com/browse/ISPN-11126 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, REST > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.0.Dev04, 10.1.6.Final > > > When using predefined caches on a container with authorization, and the caches have not been started, the health handler for the cachemanager resource fails with an authorization error. > The call should be wrapped in a SecurityAction. -- 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 Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11399?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11399: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > 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-11395) Indexing configuration serialization broken

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11395?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11395: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > Indexing configuration serialization broken > ------------------------------------------- > > Key: ISPN-11395 > URL: https://issues.redhat.com/browse/ISPN-11395 > Project: Infinispan > Issue Type: Bug > Components: Core, Embedded Querying > Affects Versions: 11.0.0.Alpha1, 10.1.3.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Dev04 > > > Some elements are not written to XML such as IndexedEntities and keytransformers -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11381) AdvancedCache.getGroup(key) may return incomplete results during state transfer

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11381?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11381: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > AdvancedCache.getGroup(key) may return incomplete results during state transfer > ------------------------------------------------------------------------------- > > Key: ISPN-11381 > URL: https://issues.redhat.com/browse/ISPN-11381 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Dev04 > > > {{AdvancedCache.getGroup(groupKey)}} returns all the keys that belong to a group. > If the originator is not an owner, the command is forwarded to the primary owner. If the originator is a primary or a backup owner for the group key, the command is executed locally. > During state transfer, a node may be a write owner for the group key but not a read owner. Currently {{GroupingInterceptor}} uses {{LocalizedCacheTopogy.isWriteOwner(groupKey)}} instead of {{isReadOwner(groupKey)}}, so it executes the command on the originator instead of forwarding it to the primary owner. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11304) Allow scaling up without state transfer

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11304?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11304: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > Allow scaling up without state transfer > --------------------------------------- > > Key: ISPN-11304 > URL: https://issues.redhat.com/browse/ISPN-11304 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Dev04 > > > We should allow a cache to scale up without performing any state transfer, but without losing the data. > To simplify things, the initial version will support a single owner, and will assume that only one node is being added at a time. > The cache must be accessible remotely, but since information about the location of the keys is not accessible from the client, the client is expected to ignore ownership and use a round-robin access strategy. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11300) Add internal metadata to cache entries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11300?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11300: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > Add internal metadata to cache entries > -------------------------------------- > > Key: ISPN-11300 > URL: https://issues.redhat.com/browse/ISPN-11300 > Project: Infinispan > Issue Type: Sub-task > Components: Cross-Site Replication > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 11.0.0.Dev04 > > > IRAC will need versioning to handle the async update correctly. This version is internal an it shouldn't be exposed to the user; so Metadata.version() can't be used. > Add internal metadata to cache entries. After this is fixed, the internal metadata will be added to the persistence and commands. > Also, optimistic transaction versions need to be moved here. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11296) StateResponseOrderingTest uncaught IllegalArgumentException

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11296?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11296: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > StateResponseOrderingTest uncaught IllegalArgumentException > ----------------------------------------------------------- > > Key: ISPN-11296 > URL: https://issues.redhat.com/browse/ISPN-11296 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Dev04 > > > I think initially I wanted {{MatchCountMatcher}} to count from 1 and handle {{matchCount == 0}} as matching all invocations. All the callers now assume 0 is the first invocation, but the code kept working because the exception was not caught. > {noformat} > java.lang.IllegalStateException: State st:after_first_state_response exited twice > at org.infinispan.test.concurrent.StateSequencer.exit(StateSequencer.java:242) > at org.infinispan.test.concurrent.StateSequencer.advance(StateSequencer.java:316) > at org.infinispan.test.concurrent.StateSequencerUtil.advanceMultiple(StateSequencerUtil.java:103) > at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.advance(InboundRpcSequencerAction.java:101) > at org.infinispan.test.concurrent.InboundRpcSequencerAction$SequencerPerCacheInboundInvocationHandler.lambda$handle$0(InboundRpcSequencerAction.java:82) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invokedComplete(BaseBlockingRunnable.java:130) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:111) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:72) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:41) > 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) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11295) InfinispanLock needs to block on a blocking thread but continue its operation on a non blocking thread

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11295?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11295: ----------------------------------- Fix Version/s: 11.0.0.Dev04 (was: 11.0.0.Dev03) > InfinispanLock needs to block on a blocking thread but continue its operation on a non blocking thread > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-11295 > URL: https://issues.redhat.com/browse/ISPN-11295 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04 > > > The InfinispanLock#toInvocationStage can block waiting for the lock. If this happens it needs to block on the blocking thread but then continue on a non blocking thread. -- 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