October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4820) Change Size method on Cache to return the contents of the entire cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4820?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4820: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155674 > Change Size method on Cache to return the contents of the entire cluster > ------------------------------------------------------------------------ > > Key: ISPN-4820 > URL: https://issues.jboss.org/browse/ISPN-4820 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR2 > > > It has been discussed to change the size method to properly reflect the contents of the entire cache instead of just locally. > http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015524.html > It seems for now we should do this via the entry iterator for distributed caches otherwise use current implementation for local. Or something of that sort. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4673) Split-brain: get() returns null when all owners are removed from view

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4673?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4673: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1152886|https://bugzilla.redhat.com/show_bug.cgi?id=1152886] from POST to MODIFIED > Split-brain: get() returns null when all owners are removed from view > --------------------------------------------------------------------- > > Key: ISPN-4673 > URL: https://issues.jboss.org/browse/ISPN-4673 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > After split brain: when calling {{cache.get()}} for an entry that has all owners in the missing partition, JGroupsTransport removes the target nodes that are no longer members and then returns empty response map > BaseDistributionInterceptor.invokeClusterGetCommandRemotely takes empty map as null response, although the entry is just not available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4867) HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4867?page=com.atlassian.jira.plugin.... ] Work on ISPN-4867 started by Galder Zamarreño. ---------------------------------------------- > HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures > ------------------------------------------------------------------- > > Key: ISPN-4867 > URL: https://issues.jboss.org/browse/ISPN-4867 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException: org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: org/infinispan/server/test/client/hotrod/HotRodCustomMarshallerEventIT$Id > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:284) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:86) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:72) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testCustomEvents(AbstractRemoteCacheIT.java:855) > {noformat} > Tests {{testCustomEventsDynamic}}, {{testEventFilteringDynamic}}, {{testEventFilteringStatic}} fail with the same error message. > Failing since http://ci.infinispan.org/viewLog.html?buildTypeId=bt8&buildId=12713 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4867) HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4867?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-4867: ---------------------------------------- Replicated with: {code}mvn verify -Dit.test="org/infinispan/server/test/client/hotrod/*" -pl server/integration/testsuite{code} > HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures > ------------------------------------------------------------------- > > Key: ISPN-4867 > URL: https://issues.jboss.org/browse/ISPN-4867 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException: org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: org/infinispan/server/test/client/hotrod/HotRodCustomMarshallerEventIT$Id > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:284) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:86) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:72) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testCustomEvents(AbstractRemoteCacheIT.java:855) > {noformat} > Tests {{testCustomEventsDynamic}}, {{testEventFilteringDynamic}}, {{testEventFilteringStatic}} fail with the same error message. > Failing since http://ci.infinispan.org/viewLog.html?buildTypeId=bt8&buildId=12713 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4755) TransportConfigurationBuilder.read(...) assumes Transport instance has default constructor

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4755?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4755: --------------------------------------- I recently had the misfortune to use the transportconfigurationbuilder and I would welcome anything that could improve things. > TransportConfigurationBuilder.read(...) assumes Transport instance has default constructor > ------------------------------------------------------------------------------------------ > > Key: ISPN-4755 > URL: https://issues.jboss.org/browse/ISPN-4755 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 7.0.0.Beta2 > Reporter: Paul Ferraro > > While upgrading WildFly to Infinispan 7.0, I encountered an InstantiationException in a call to GlobalConfigurationBuilder.read(...). The culprit is the following commit: > https://github.com/infinispan/infinispan/commit/b6190774725ed38f67ee7787a... > Specifically, during TransportConfigurationBuilder.read(...) a new Transport instance is constructed using the default constructor of the transport class. However, the Transport object might not have a default constructor. Such is the case with WildFly's ChannelTransport. > See: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/src/... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4852) PartitionHandling: support replicated caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4852?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4852: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1155606|https://bugzilla.redhat.com/show_bug.cgi?id=1155606] from NEW to ASSIGNED > PartitionHandling: support replicated caches > -------------------------------------------- > > Key: ISPN-4852 > URL: https://issues.jboss.org/browse/ISPN-4852 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > ISPN-4574 already did most of the job, but the PartitionHandlingManager component wasn't created for replicated caches. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4856) PartitionHandling: majority check in PreferConsistencyStrategy is incorrect

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4856?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4856: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1155602|https://bugzilla.redhat.com/show_bug.cgi?id=1155602] from NEW to ASSIGNED > PartitionHandling: majority check in PreferConsistencyStrategy is incorrect > --------------------------------------------------------------------------- > > Key: ISPN-4856 > URL: https://issues.jboss.org/browse/ISPN-4856 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > If the cluster has 3 members and one of them crashes, the remaining 2 should stay available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4776) The topology id for the merged cache topology is not always bigger than all the partition topology ids

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4776: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1155611|https://bugzilla.redhat.com/show_bug.cgi?id=1155611] from NEW to ASSIGNED > The topology id for the merged cache topology is not always bigger than all the partition topology ids > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-4776 > URL: https://issues.jboss.org/browse/ISPN-4776 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR2, 7.0.0.Final > > > With the ISPN-4574 fix, I changed the merge algorithm to pick the partition with the most members (both in the _stable_ topology and in the _current_ topology) instead of the partition with the highest topology id. > However, the biggest topology is not necessarily the partition with the highest topology id, so it's possible that some nodes will ignore the merged topology because they already have a higher topology installed. This happened once in ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit: > {noformat} > 00:24:59,286 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Recovered 3 partition(s) for cache cache: [CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeL-25322: 60+0]}, pendingCH=null, unionCH=null}, CacheTopology{id=6, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+10, NodeN-6727: 30+10]}, pendingCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+30, NodeN-6727: 30+30]}, unionCH=null}, CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}] > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Updating topologies after merge for cache cache, current topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, stable topology = CacheTopology{id=4, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (3)[, NodeL-25322: 20+20, NodeM-12972: 20+20, NodeN-6727: 20+20]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache cache, topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,288 TRACE (transport-thread-NodeL-p33097-t3:) [LocalTopologyManagerImpl] Ignoring consistent hash update for cache cache, current topology is 8: CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null} > {noformat} > Failure logs here: http://ci.infinispan.org/viewLog.html?buildId=12364&buildTypeId=Infinispa... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4722) CLI remove is not cluster-wide

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4722?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4722: --------------------------------------- the CLI remove command simply invokes a cache.remove, so I don't know why you're seeing this behaviour. Is this with a sync cache ? > CLI remove is not cluster-wide > ------------------------------ > > Key: ISPN-4722 > URL: https://issues.jboss.org/browse/ISPN-4722 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 6.0.2.Final, 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 7.0.0.Final > > > In CLI, the "remove" command does not delete entries in all nodes of a clustered environment, only the local copy. However, the "put" command does write in all nodes. Is it the expected behavior? See example below: > {code} > node 1 > put k1 v1 > get k1 -> v1 > node 2 > get k1 -> v1 > node 1 > remove k1 > get k1 -> null > node 2 > get k1 -> v1 > {code} > I know that these commands provided by CLI are not used in real world, but they are useful to demonstrate the correct configuration of a JDG cluster. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4776) The topology id for the merged cache topology is not always bigger than all the partition topology ids

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4776: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155611 > The topology id for the merged cache topology is not always bigger than all the partition topology ids > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-4776 > URL: https://issues.jboss.org/browse/ISPN-4776 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR2, 7.0.0.Final > > > With the ISPN-4574 fix, I changed the merge algorithm to pick the partition with the most members (both in the _stable_ topology and in the _current_ topology) instead of the partition with the highest topology id. > However, the biggest topology is not necessarily the partition with the highest topology id, so it's possible that some nodes will ignore the merged topology because they already have a higher topology installed. This happened once in ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit: > {noformat} > 00:24:59,286 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Recovered 3 partition(s) for cache cache: [CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeL-25322: 60+0]}, pendingCH=null, unionCH=null}, CacheTopology{id=6, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+10, NodeN-6727: 30+10]}, pendingCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+30, NodeN-6727: 30+30]}, unionCH=null}, CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}] > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Updating topologies after merge for cache cache, current topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, stable topology = CacheTopology{id=4, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (3)[, NodeL-25322: 20+20, NodeM-12972: 20+20, NodeN-6727: 20+20]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache cache, topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,288 TRACE (transport-thread-NodeL-p33097-t3:) [LocalTopologyManagerImpl] Ignoring consistent hash update for cache cache, current topology is 8: CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null} > {noformat} > Failure logs here: http://ci.infinispan.org/viewLog.html?buildId=12364&buildTypeId=Infinispa... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 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 October 2014