August 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-12175) Docs: Index page update for Operator versions and SB Starter

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12175?page=com.atlassian.jira.plugi... ] Ryan Emerson resolved ISPN-12175. --------------------------------- Fix Version/s: 12.0.0.Dev02 Resolution: Done > Docs: Index page update for Operator versions and SB Starter > ------------------------------------------------------------ > > Key: ISPN-12175 > URL: https://issues.redhat.com/browse/ISPN-12175 > Project: Infinispan > Issue Type: Enhancement > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 12.0.0.Dev02 > > > [https://infinispan.org/docs/dev/index.html] - points to 2.0 as dev and 1.1 as stable - also need to update the SB starter doc link because this is part of the core doc set in 12 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12225) Cluster in a confusing state after restarted from graceful shutdown - no hint for waiting on complete restarted

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-12225: --------------------------------------- Summary: Cluster in a confusing state after restarted from graceful shutdown - no hint for waiting on complete restarted Key: ISPN-12225 URL: https://issues.redhat.com/browse/ISPN-12225 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 12.0.0.Dev01, 11.0.3.Final Reporter: Wolf-Dieter Fink After a cluster is stopped with "shutdown cluster" and incomplete restart there is no WARN or INFO message that the cluster is in an incomplete state if not all nodes are back. If there is a single node started it is still possible to add new entries!! As well as entries can be read. But the server will throw Exceptions. The expectation is to have log messages with a statement that the cluster of (a,b, ...) is incomplete started after graceful shutdown and the missing nodes are (x,y,...) It should not be possible to access caches. There should be a CLI/JMX option to interrupt the graceful start and set the cluster to a working state - even if there is a possible loss of data in this case. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12224) Cluster in a confusing state after restarted from graceful shutdown - no hint for waiting on complete restarted

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-12224: --------------------------------------- Summary: Cluster in a confusing state after restarted from graceful shutdown - no hint for waiting on complete restarted Key: ISPN-12224 URL: https://issues.redhat.com/browse/ISPN-12224 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 11.0.3.Final, 12.0.0.Dev01 Reporter: Wolf-Dieter Fink After a cluster is stopped with "shutdown cluster" and incomplete restart there is no WARN or INFO message that the cluster is in an incomplete state if not all nodes are back. If there is a single node started it is still possible to add new entries!! As well as entries can be read. But the server will throw Exceptions. The expectation is to have log messages with a statement that the cluster of (a,b, ...) is incomplete started after graceful shutdown and the missing nodes are (x,y,...) It should not be possible to access caches. There should be a CLI/JMX option to interrupt the graceful start and set the cluster to a working state - even if there is a possible loss of data in this case. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12176) Docs: Separate Off Heap Config from Eviction

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12176?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-12176. ------------------------------ Resolution: Duplicate Did this as part of ISPN-12108 > Docs: Separate Off Heap Config from Eviction > -------------------------------------------- > > Key: ISPN-12176 > URL: https://issues.redhat.com/browse/ISPN-12176 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > In the Configuration Guide, off heap storage configuration should be de-coupled from eviction. "Configuring the Data Container" should include off heap, eviction, expiration, encoding. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12108) Docs: Endpoint interoperability

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12108?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-12108. ------------------------------ > Docs: Endpoint interoperability > ------------------------------- > > Key: ISPN-12108 > URL: https://issues.redhat.com/browse/ISPN-12108 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 12.0.0.Dev02 > > > Doc edits for styling and consistency. Convert to user story. Memcached is deprecated so should either remove references or conditionalize as community only. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-12218: --------------------------------- Status: Open (was: New) > Indexed caches with non-indexed entities query inconsistency > ------------------------------------------------------------ > > Key: ISPN-12218 > URL: https://issues.redhat.com/browse/ISPN-12218 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 11.0.3.Final > Reporter: Gustavo Fernandes > Priority: Major > Attachments: IndexedCacheNonIndexedQueryTest.java > > > When a cache is indexed, but the protobuf entitiy is not: > "FROM Entity" returns zero results > "FROM Entity WHERE <predicate>" return results > It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12223) Confusing behaviour in case of joining nodes if a partition is DEGRADED

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-12223?page=com.atlassian.jira.plugi... ] Wolf-Dieter Fink reopened ISPN-12223: ------------------------------------- Assignee: Dan Berindei > Confusing behaviour in case of joining nodes if a partition is DEGRADED > ----------------------------------------------------------------------- > > Key: ISPN-12223 > URL: https://issues.redhat.com/browse/ISPN-12223 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Partition Handling > Affects Versions: 11.0.3.Final > Reporter: Wolf-Dieter Fink > Assignee: Dan Berindei > Priority: Major > > In case of a cluster split into 2 partitions (i.e. 2+2) where both sides will go in DEGRADED mode (DENY_READ_WRITES) the behavior for the user is confusing. > > Start a new node, which try to join the cluster will fail with a state-transfer timeout , which is unexpected and leads to confusion. > It would be better if the node can finish the state-transfer and log a WARN message that the ST will be delayed, the node is not functional because of the DEGRADED state > The same will happen if one of the nodes in DEGRADED mode will be restarted for some reason, also if the machine driving the instances has crashed. > In this case the nodes are not considered as the members of the last stable cluster-view and will join like every other new node. > > Logging and behaviour should be enhanced that > a) new nodes will not fail but show DEGRADED mode and log a WARN message > b) as soon as the cluster becomes AVAILABLE the nodes are merged into the cluster > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12223) Confusing behaviour in case of joining nodes if a partition is DEGRADED

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-12223?page=com.atlassian.jira.plugi... ] Wolf-Dieter Fink closed ISPN-12223. ----------------------------------- Resolution: Duplicate Issue > Confusing behaviour in case of joining nodes if a partition is DEGRADED > ----------------------------------------------------------------------- > > Key: ISPN-12223 > URL: https://issues.redhat.com/browse/ISPN-12223 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Partition Handling > Affects Versions: 11.0.3.Final > Reporter: Wolf-Dieter Fink > Priority: Major > > In case of a cluster split into 2 partitions (i.e. 2+2) where both sides will go in DEGRADED mode (DENY_READ_WRITES) the behavior for the user is confusing. > > Start a new node, which try to join the cluster will fail with a state-transfer timeout , which is unexpected and leads to confusion. > It would be better if the node can finish the state-transfer and log a WARN message that the ST will be delayed, the node is not functional because of the DEGRADED state > The same will happen if one of the nodes in DEGRADED mode will be restarted for some reason, also if the machine driving the instances has crashed. > In this case the nodes are not considered as the members of the last stable cluster-view and will join like every other new node. > > Logging and behaviour should be enhanced that > a) new nodes will not fail but show DEGRADED mode and log a WARN message > b) as soon as the cluster becomes AVAILABLE the nodes are merged into the cluster > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12223) Confusing behaviour in case of joining nodes if a partition is DEGRADED

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-12223: --------------------------------------- Summary: Confusing behaviour in case of joining nodes if a partition is DEGRADED Key: ISPN-12223 URL: https://issues.redhat.com/browse/ISPN-12223 Project: Infinispan Issue Type: Enhancement Components: Core, Partition Handling Affects Versions: 11.0.3.Final Reporter: Wolf-Dieter Fink In case of a cluster split into 2 partitions (i.e. 2+2) where both sides will go in DEGRADED mode (DENY_READ_WRITES) the behavior for the user is confusing. Start a new node, which try to join the cluster will fail with a state-transfer timeout , which is unexpected and leads to confusion. It would be better if the node can finish the state-transfer and log a WARN message that the ST will be delayed, the node is not functional because of the DEGRADED state The same will happen if one of the nodes in DEGRADED mode will be restarted for some reason, also if the machine driving the instances has crashed. In this case the nodes are not considered as the members of the last stable cluster-view and will join like every other new node. Logging and behaviour should be enhanced that a) new nodes will not fail but show DEGRADED mode and log a WARN message b) as soon as the cluster becomes AVAILABLE the nodes are merged into the cluster -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ] Gustavo Fernandes edited comment on ISPN-12218 at 8/13/20 3:50 AM: ------------------------------------------------------------------- [~anistor] I am not sure what to do here. This happens in 11.x (haven't tested on 12). I attached a reproducer for 11.x. It seems to me that it should throw an error rather than trying to query , given that the user configures {{addIndexedEntity("Entity")}} with a non-indexed entity was (Author: gustavonalle): [~anistor] I am not sure what to do here. This happens in 11.x (haven't tested on 12). I attached a reproducer for 11.x. It seems to me that it should throw an error rather them trying to the query when the user configures {{addIndexedEntity("Entity")}} with a non-indexed entity > Indexed caches with non-indexed entities query inconsistency > ------------------------------------------------------------ > > Key: ISPN-12218 > URL: https://issues.redhat.com/browse/ISPN-12218 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 11.0.3.Final > Reporter: Gustavo Fernandes > Priority: Major > Attachments: IndexedCacheNonIndexedQueryTest.java > > > When a cache is indexed, but the protobuf entitiy is not: > "FROM Entity" returns zero results > "FROM Entity WHERE <predicate>" return results > It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 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 August 2020