April 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6187) Nodes should be recognized if they join a cluster again if PartitionHandling is active

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6187?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-6187: ---------------------------------- Assignee: Dan Berindei > Nodes should be recognized if they join a cluster again if PartitionHandling is active > -------------------------------------------------------------------------------------- > > Key: ISPN-6187 > URL: https://issues.jboss.org/browse/ISPN-6187 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Wolf-Dieter Fink > Assignee: Dan Berindei > Labels: partition_handling > > If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. > In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. > As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. > As a result the node join as known and can be > # filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. > # filled with data if at least one owner is inside the remaining cluster > equal splitt with numOwner>numNode/2 > # full cluster rebalance with WARN/ERROR if there is a possible loss of data -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6187) Nodes should be recognized if they join a cluster again if PartitionHandling is active

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6187?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6187: ------------------------------- Status: Open (was: New) > Nodes should be recognized if they join a cluster again if PartitionHandling is active > -------------------------------------------------------------------------------------- > > Key: ISPN-6187 > URL: https://issues.jboss.org/browse/ISPN-6187 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Wolf-Dieter Fink > Assignee: Dan Berindei > Labels: partition_handling > > If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. > In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. > As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. > As a result the node join as known and can be > # filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. > # filled with data if at least one owner is inside the remaining cluster > equal splitt with numOwner>numNode/2 > # full cluster rebalance with WARN/ERROR if there is a possible loss of data -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6187) Nodes should be recognized if they join a cluster again if PartitionHandling is active

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6187?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6187: ------------------------------------ # If the partition is already AVAILABLE, we will do a rebalance and transfer state to the joiner regardless of the persistent UUID. # Agree, we could make a DEGRADED partition AVAILABLE if the new joiner makes it a majority partition and the partition already had a copy of each segment (also possible with {{numOwners <= numNodes/2}}, as long as {{numOwners > 2}}). After we mark the partition as AVAILABLE, we're in case #1 and we should do a rebalance with the current members. # I think the whole point of enabling partition handling is to not allow the application to proceed with incomplete data, so I don't think we should ever rebalance if we don't have a copy of each segment. > Nodes should be recognized if they join a cluster again if PartitionHandling is active > -------------------------------------------------------------------------------------- > > Key: ISPN-6187 > URL: https://issues.jboss.org/browse/ISPN-6187 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Wolf-Dieter Fink > Labels: partition_handling > > If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. > In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. > As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. > As a result the node join as known and can be > # filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. > # filled with data if at least one owner is inside the remaining cluster > equal splitt with numOwner>numNode/2 > # full cluster rebalance with WARN/ERROR if there is a possible loss of data -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6250) The keys/values in TaskContext.getCache() are serialized in Server Task

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6250?page=com.atlassian.jira.plugin.... ] Anna Manukyan commented on ISPN-6250: ------------------------------------- Hi Michal, yes the issue is still there. The test works with workaround, i.e. unmarshalling the entries separately. Best regards, Anna. > The keys/values in TaskContext.getCache() are serialized in Server Task > ----------------------------------------------------------------------- > > Key: ISPN-6250 > URL: https://issues.jboss.org/browse/ISPN-6250 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Reporter: Anna Manukyan > Assignee: Michał Szynkiewicz > Attachments: LocalServerTaskIT.java, LocalTestServerTask.java > > > While trying to access cache entries in Server task, marshaller is required for unmarshalling them. > The test is running on the https://github.com/infinispan/infinispan/blob/master/server/integration/t... configuration. > Please find the sources attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6187) Nodes should be recognized if they join a cluster again if PartitionHandling is active

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6187?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6187: ------------------------------- Description: If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. As a result the node join as known and can be 1. filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. 2. filled with data if at least one owner is inside the remaining cluster equal splitt with numOwner>numNode/2 3. full cluster rebalance with WARN/ERROR if there is a possible loss of data was: If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. As a result the node join as known and can be - filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. - filled with data if at least one owner is inside the remaining cluster equal splitt with numOwner>numNode/2 - full cluster rebalance with WARN/ERROR if there is a possible loss of data > Nodes should be recognized if they join a cluster again if PartitionHandling is active > -------------------------------------------------------------------------------------- > > Key: ISPN-6187 > URL: https://issues.jboss.org/browse/ISPN-6187 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Wolf-Dieter Fink > Labels: partition_handling > > If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. > In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. > As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. > As a result the node join as known and can be > 1. filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. > 2. filled with data if at least one owner is inside the remaining cluster > equal splitt with numOwner>numNode/2 > 3. full cluster rebalance with WARN/ERROR if there is a possible loss of data -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6187) Nodes should be recognized if they join a cluster again if PartitionHandling is active

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6187?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6187: ------------------------------- Description: If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. As a result the node join as known and can be # filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. # filled with data if at least one owner is inside the remaining cluster equal splitt with numOwner>numNode/2 # full cluster rebalance with WARN/ERROR if there is a possible loss of data was: If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. As a result the node join as known and can be 1. filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. 2. filled with data if at least one owner is inside the remaining cluster equal splitt with numOwner>numNode/2 3. full cluster rebalance with WARN/ERROR if there is a possible loss of data > Nodes should be recognized if they join a cluster again if PartitionHandling is active > -------------------------------------------------------------------------------------- > > Key: ISPN-6187 > URL: https://issues.jboss.org/browse/ISPN-6187 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Wolf-Dieter Fink > Labels: partition_handling > > If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. > In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. > As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. > As a result the node join as known and can be > # filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. > # filled with data if at least one owner is inside the remaining cluster > equal splitt with numOwner>numNode/2 > # full cluster rebalance with WARN/ERROR if there is a possible loss of data -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5655) MissingFormatArgumentException thrown by PreferConsistencyStrategy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5655?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5655: ----------------------------------------------- Jakub Senko <jsenko(a)redhat.com> changed the Status of [bug 1412752|https://bugzilla.redhat.com/show_bug.cgi?id=1412752] from POST to MODIFIED > MissingFormatArgumentException thrown by PreferConsistencyStrategy > ------------------------------------------------------------------ > > Key: ISPN-5655 > URL: https://issues.jboss.org/browse/ISPN-5655 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Beta2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 8.0.0.Beta3, 8.0.0.Final > > > Exception thrown due to line 197 in PreferConsistencyStrategy.java > 2015-08-03 10:30:38,873 ERROR Unable to format msg: After merge, cache %s has recovered and is entering available mode java.util.MissingFormatArgumentException: Format specifier '%s' > at java.util.Formatter.format(Formatter.java:2519) > at java.util.Formatter.format(Formatter.java:2455) > at java.lang.String.format(String.java:2928) > at org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:88) > at org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:60) > at org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:68) > at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:36) > at org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:196) > at org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:55) > at org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:71) > at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:108) > at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:99) > at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:430) > at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:409) > at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:412) > at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:367) > at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:112) > at org.jboss.logging.Log4j2Logger.doLogf(Log4j2Logger.java:66) > at org.jboss.logging.Logger.logf(Logger.java:2445) > at org.jboss.logging.DelegatingBasicLogger.debugf(DelegatingBasicLogger.java:344) > at org.infinispan.partitionhandling.impl.PreferConsistencyStrategy.onPartitionMerge(PreferConsistencyStrategy.java:198) > at org.infinispan.topology.ClusterCacheStatus.doMergePartitions(ClusterCacheStatus.java:509) > at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:383) > at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:380) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173) > at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7121) Remove Expired doesn't work with no auto commit in a clustered cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-7121?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-7121: ----------------------------------------------- Jakub Senko <jsenko(a)redhat.com> changed the Status of [bug 1379414|https://bugzilla.redhat.com/show_bug.cgi?id=1379414] from POST to MODIFIED > Remove Expired doesn't work with no auto commit in a clustered cache > -------------------------------------------------------------------- > > Key: ISPN-7121 > URL: https://issues.jboss.org/browse/ISPN-7121 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Alpha4 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.2.5.Final, 9.0.0.Beta1, 9.0.0.Final > > > Expired events are not generated for clustered caches which has transactions without auto commit. Local caches work fine though. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7080) NPE in CacheNotifierImpl by LIRS eviction listener

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-7080?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-7080: ----------------------------------------------- Jakub Senko <jsenko(a)redhat.com> changed the Status of [bug 1382273|https://bugzilla.redhat.com/show_bug.cgi?id=1382273] from POST to MODIFIED > NPE in CacheNotifierImpl by LIRS eviction listener > --------------------------------------------------- > > Key: ISPN-7080 > URL: https://issues.jboss.org/browse/ISPN-7080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Environment: * Infinispan branch: Upstream master > Reporter: Ted Won > Assignee: William Burns > Labels: core, eviction, lirs > Fix For: 9.0.0.Beta1 > > > The LIRSEvictionFunctionalTest.testSimpleEvictionMaxEntries unit test method in core module fails and throws NPE in CacheNotifierImpl.notifyCacheEntriesEvicted method when trying to reinsert the first keys again. > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... > It reproduces only with LIRS eviction strategy and eviction listener. > However, LRU and UNORDERED eviction strategies are working properly. > It makes impossible the use of eviction listeners with LIRS eviction strategy. > It's able to reproduce by: > - inserting 20 keys - values in a 10 sized cache ( keys from key-1 to key-20), > - and then reinsert the first 10 keys (key-1 to key-10) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7763) User Guide Improvement: Create a remote cache via JCache API

by Fei Chen (JIRA)

Fei Chen created ISPN-7763: ------------------------------ Summary: User Guide Improvement: Create a remote cache via JCache API Key: ISPN-7763 URL: https://issues.jboss.org/browse/ISPN-7763 Project: Infinispan Issue Type: Enhancement Reporter: Fei Chen Priority: Minor Update User Guide to describe how to create a remote cache (client-server mode) via JCache API -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2017