October 2014 - infinispan-issues - Jboss List Archives

[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 updated ISPN-4867: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2981 > 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-4693) Locks acquired before a partition will never be released

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4693: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155692 > Locks acquired before a partition will never be released > -------------------------------------------------------- > > Key: ISPN-4693 > URL: https://issues.jboss.org/browse/ISPN-4693 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.CR2, 7.0.0.Final > > > Consider the following case: > 1. A prepares a transaction for key K on nodes B and C. > 2. The primary owner B acquires and registers this lock. > 3. The cluster partitions and A,C remain in partition one, and B in a separate partition. > 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B. > 5. B rejoins the cluster. It still has a lock acquired for key K. > This can lead to a lock being acquired indefinitely. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3830: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1155688|https://bugzilla.redhat.com/show_bug.cgi?id=1155688] from NEW to ASSIGNED > Conditional Operation can fail erroneously during ST > ---------------------------------------------------- > > Key: ISPN-3830 > URL: https://issues.jboss.org/browse/ISPN-3830 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Reporter: William Burns > Assignee: Dan Berindei > Fix For: 7.0.0.CR2 > > > Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful. > This however can have the following issue. > k1 owned by N1, N2 > # N3 updates k1 sending conditional command to N1 > # N1 receives command and starts running it (passes topology block) > # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container. > # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException > # N3 gets response that command failed, but it could have worked had it gone to a real owner. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3830: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155688 > Conditional Operation can fail erroneously during ST > ---------------------------------------------------- > > Key: ISPN-3830 > URL: https://issues.jboss.org/browse/ISPN-3830 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Reporter: William Burns > Assignee: Dan Berindei > Fix For: 7.0.0.CR2 > > > Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful. > This however can have the following issue. > k1 owned by N1, N2 > # N3 updates k1 sending conditional command to N1 > # N1 receives command and starts running it (passes topology block) > # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container. > # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException > # N3 gets response that command failed, but it could have worked had it gone to a real owner. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4836) Change entrySet, keySet and values to be backing maps

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4836?page=com.atlassian.jira.plugin.... ] Work on ISPN-4836 started by William Burns. ------------------------------------------- > Change entrySet, keySet and values to be backing maps > ----------------------------------------------------- > > Key: ISPN-4836 > URL: https://issues.jboss.org/browse/ISPN-4836 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > > Currently the entrySet, keySet and values methods are copies of data at the time of invocation. They do not allow for seeing updated values or actually updating the cache through them. It would be nice to support these operations as well. -- 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 ASSIGNED to POST > 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-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 MODIFIED to POST > 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-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 ASSIGNED to MODIFIED > 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-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 ASSIGNED to POST > 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-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 commented on ISPN-4820: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1155674|https://bugzilla.redhat.com/show_bug.cgi?id=1155674] from NEW to MODIFIED > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2014