February 2020 - infinispan-issues

[JBoss JIRA] (ISPN-11294) CLI allows "cd" below a cache

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11294?page=com.atlassian.jira.plugi... ] Ryan Emerson resolved ISPN-11294. --------------------------------- Resolution: Done > CLI allows "cd" below a cache > ----------------------------- > > Key: ISPN-11294 > URL: https://issues.redhat.com/browse/ISPN-11294 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 10.1.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.2.Final, 11.0.0.Alpha1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11297) Rejoining nodes with global state may have their caches corrupted if there is a config mismatch

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-11297?page=com.atlassian.jira.plugi... ] Wolf-Dieter Fink commented on ISPN-11297: ----------------------------------------- There should be a start option to start clean and remove the existing configuration and data. This should be mentioned within the error message > Rejoining nodes with global state may have their caches corrupted if there is a config mismatch > ----------------------------------------------------------------------------------------------- > > Key: ISPN-11297 > URL: https://issues.redhat.com/browse/ISPN-11297 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 10.1.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > > With a persistent global state enabled, when a node that was previously part of a cluster rejoins it currently processes caches from the cluster state before the ones from the local state. This means that, if the cache configuration is incompatible, it will be overwritten with the one coming from the cluster. > When joining the node should perform compatibility checks between caches in the cluster state and the local state before proceeding with creating them. If a mismatch is found, it should fail fast. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11297) Rejoining nodes with global state may have their local caches corrupted

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-11297: -------------------------------------- Summary: Rejoining nodes with global state may have their local caches corrupted Key: ISPN-11297 URL: https://issues.redhat.com/browse/ISPN-11297 Project: Infinispan Issue Type: Bug Components: Configuration, Core Affects Versions: 10.1.1.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant With a persistent global state enabled, when a node that was previously part of a cluster rejoins it currently processes caches from the cluster state before the ones from the local state. This means that, if the cache configuration is incompatible, it will be overwritten with the one coming from the cluster. When joining the node should perform compatibility checks between caches in the cluster state and the local state before proceeding with creating them. If a mismatch is found, it should fail fast. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11297) Rejoining nodes with global state may have their caches corrupted if there is a config mismatch

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11297?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11297: ----------------------------------- Summary: Rejoining nodes with global state may have their caches corrupted if there is a config mismatch (was: Rejoining nodes with global state may have their local caches corrupted) > Rejoining nodes with global state may have their caches corrupted if there is a config mismatch > ----------------------------------------------------------------------------------------------- > > Key: ISPN-11297 > URL: https://issues.redhat.com/browse/ISPN-11297 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 10.1.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > > With a persistent global state enabled, when a node that was previously part of a cluster rejoins it currently processes caches from the cluster state before the ones from the local state. This means that, if the cache configuration is incompatible, it will be overwritten with the one coming from the cluster. > When joining the node should perform compatibility checks between caches in the cluster state and the local state before proceeding with creating them. If a mismatch is found, it should fail fast. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11280?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11280: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7853 > 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.Alpha1 > > > {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, 2 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11296?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11296: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7853 > 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.Alpha1 > > > 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, 2 months

1
0
0 / 0

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

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11296?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11296: -------------------------------- Status: Open (was: New) > 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.Alpha1 > > > 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, 2 months

1
0
0 / 0

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

by Dan Berindei (Jira)

Dan Berindei created ISPN-11296: ----------------------------------- Summary: 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 Fix For: 11.0.0.Alpha1 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11197) Server Docs: JMX Monitoring

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11197?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11197: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.1.2.Final 11.0.0.Alpha1 Resolution: Done > Server Docs: JMX Monitoring > --------------------------- > > Key: ISPN-11197 > URL: https://issues.redhat.com/browse/ISPN-11197 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 10.1.2.Final, 11.0.0.Alpha1 > > > Need to update server docs for JMX monitoring. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

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 Will Burns (Jira)

Will Burns created ISPN-11295: --------------------------------- Summary: 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 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, 2 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 February 2020