February 2020 - infinispan-issues

[JBoss JIRA] (ISPN-11261) GlobalConfigurationManager should use blocking threads when starting caches

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11261?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11261: ----------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > GlobalConfigurationManager should use blocking threads when starting caches > --------------------------------------------------------------------------- > > Key: ISPN-11261 > URL: https://issues.redhat.com/browse/ISPN-11261 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Beta1 > > > The GlobalConfigurationMangerImpl starts caches via a thread pool. Currently this thread pool is the configured non blocking thread pool. We should move this instead to the blocking thread pool until ISPN-9744 can be fixed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11262) Remove deprecated eviction configuration values

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11262?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11262: ----------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Remove deprecated eviction configuration values > ----------------------------------------------- > > Key: ISPN-11262 > URL: https://issues.redhat.com/browse/ISPN-11262 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Beta1 > > > EvictionStrategy used to include things such as FIFO, UNORDERED, LRU, LIRS. These are never used anymore as each container has only a single eviction strategy it supports. Instead eviction strategy has been used for NONE, MANUAL, REMOVE or EXCEPTION moving forward. > Off heap memory address has been deprecated since 10.0 as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11266) Split CacheTopologyControlCommand into individual commands

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11266?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11266: ----------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Split CacheTopologyControlCommand into individual commands > ---------------------------------------------------------- > > Key: ISPN-11266 > URL: https://issues.redhat.com/browse/ISPN-11266 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Beta1 > > > Currently the {{CacheTopologyControlCommand}} uses a Type field and a switch statement to differentiate between various topology actions. This worked well for the old Externalizer approach, however it does not fit well with protobuf messages. Instead, the CacheTopologyControlCommand should be split into individual commands, e.g. a TopologyJoinCommand etc. > This enables the logic of the command types to be separated, making it easier to maintain backwards compatibility in the long term. Each command will use a ProtoStream TypeId in the range of 1000 -> 3999, so the cost of two bytes is the same as the existing class ID plus enum Type that we require with the single CacheTopologyControlCommand. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11267) Remove Deprecated ConcurrentHashSet/CollectionFactory/ConcurrentWeakKeyHashMap

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11267?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11267: ----------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Remove Deprecated ConcurrentHashSet/CollectionFactory/ConcurrentWeakKeyHashMap > ------------------------------------------------------------------------------ > > Key: ISPN-11267 > URL: https://issues.redhat.com/browse/ISPN-11267 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Beta1 > > > The ConcurrentHashSet/CollectionFactory/ConcurrentWeakKeyHashMap classes were deprecated in 10.0. We should remove them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11271) Convert async transport executor to the non blocking thread pool

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11271?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11271: ----------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Convert async transport executor to the non blocking thread pool > ---------------------------------------------------------------- > > Key: ISPN-11271 > URL: https://issues.redhat.com/browse/ISPN-11271 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Priority: Major > Fix For: 11.0.0.Beta1 > > > The ASYNC_TRANSPORT_EXECUTOR should be consolidated with the async thread pool and make sure that operations performed on it are not blocking. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11280) ConcurrentModificationException in ConditionFuture

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11280?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11280: ----------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > ConcurrentModificationException in ConditionFuture > -------------------------------------------------- > > Key: ISPN-11280 > URL: https://issues.redhat.com/browse/ISPN-11280 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Beta1 > > > {noformat} > java.util.ConcurrentModificationException > at java.base/java.util.IdentityHashMap$IdentityHashMapIterator.remove(IdentityHashMap.java:749) > at java.base/java.util.IdentityHashMap$EntryIterator.remove(IdentityHashMap.java:850) > at org.infinispan.util.concurrent.ConditionFuture.checkConditions(ConditionFuture.java:114) > at org.infinispan.util.concurrent.ConditionFuture.lambda$updateAsync$1(ConditionFuture.java:98) > 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 month

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.Beta1 (was: 11.0.0.Alpha1) > 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.Beta1 > > > 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 month

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.Beta1 (was: 11.0.0.Alpha1) > 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.Beta1 > > > 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11113) ScatteredDelayedAvailabilityUpdateTest takes too long

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11113?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11113: ----------------------------------- Fix Version/s: 10.1.3.Final (was: 10.1.2.Final) > ScatteredDelayedAvailabilityUpdateTest takes too long > ----------------------------------------------------- > > Key: ISPN-11113 > URL: https://issues.redhat.com/browse/ISPN-11113 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite > Affects Versions: 10.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 11.0.0.Final, 10.1.3.Final > > > Partition handling tests use {{LOCAL_PING.setClusterName()}} with a unique name to disable discovery, otherwise partitions would try to merge while they are supposed to stay separate. > But {{LOCAL_PING}} uses the cluster name on stop to remove the node from the static discovery map. If the test doesn't change the cluster name back, {{LOCAL_PING}} doesn't remove the node, the next test method sees an existing coordinator, and tries to connect to it. When a test has lots of test methods, like {{ScatteredDelayedAvailabilityUpdateTest}}, each test method leaves one more coordinator in the discovery map, and each test method takes longer to start the first method. > {noformat} > 09:08:52,758 DEBUG (testng:[]) [GMS] address=NodeA-30899, cluster=org.infinispan.partitionhandling.ScatteredDelayedAvailabilityUpdateTest[SCATTERED_SYNC, bias=NEVER, DENY_READ_WRITES], physical address=127.0.0.1:51941 > 09:08:52,774 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done] > 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475] > 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606 > 09:08:54,774 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 0 > 09:08:54,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-64297 > 09:08:56,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-64297 timed out (after 2000 ms), on try 0 > 09:08:56,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-48475 > 09:08:58,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-48475 timed out (after 2000 ms), on try 0 > 09:08:58,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-17288 > 09:09:00,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-17288 timed out (after 2000 ms), on try 0 > 09:09:00,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608 > 09:09:02,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 0 > 09:09:02,776 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done] > 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475] > 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606 > 09:09:04,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 1 > ... > 09:09:12,777 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done] > 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475] > 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608 > 09:09:14,778 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 2 > ... > 09:09:22,780 WARN (testng:[]) [GMS] NodeA-30899: too many JOIN attempts (3): becoming singleton > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

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: 10.1.3.Final (was: 10.1.2.Final) > 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: 10.1.3.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 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2020