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 commented on ISPN-4867: ---------------------------------------- @Dan, not sure, the issue is different. I don't see how the entry count could affect the deployment or construction of the jar. > 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 > 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 reopened ISPN-4867: ------------------------------------ Assignee: 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-4813) JMX returns wrong number of cache entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4813?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4813: ----------------------------------- Fix Version/s: 7.0.0.Final > JMX returns wrong number of cache entries > ----------------------------------------- > > Key: ISPN-4813 > URL: https://issues.jboss.org/browse/ISPN-4813 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Remote Protocols, Server > Reporter: Vojtech Juranek > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > Number of cache entries ({{numberOfEntries}}) provided by JMX is wrong. {{HotRodRemoteCacheIT#testPutAsyc}} fails with assert error (see bellow), because JMX returns wrong number of entries in the cache. When debugging the test, number of entries in the cache is correct (100 - obrained e.g. by {{cache.getBulk().size()}}), but JMX return wrong number (100). Even on cleared cache JMX return that it contains 3 entries. When the {{clear}} operation is called via JMX, JMX show correct number (0). > {noformat} > java.lang.AssertionError: expected:<100> but was:<103> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutAsync(AbstractRemoteCacheIT.java:574) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4813) JMX returns wrong number of cache entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4813?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4813: ----------------------------------- Status: Open (was: New) > JMX returns wrong number of cache entries > ----------------------------------------- > > Key: ISPN-4813 > URL: https://issues.jboss.org/browse/ISPN-4813 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Remote Protocols, Server > Reporter: Vojtech Juranek > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > Number of cache entries ({{numberOfEntries}}) provided by JMX is wrong. {{HotRodRemoteCacheIT#testPutAsyc}} fails with assert error (see bellow), because JMX returns wrong number of entries in the cache. When debugging the test, number of entries in the cache is correct (100 - obrained e.g. by {{cache.getBulk().size()}}), but JMX return wrong number (100). Even on cleared cache JMX return that it contains 3 entries. When the {{clear}} operation is called via JMX, JMX show correct number (0). > {noformat} > java.lang.AssertionError: expected:<100> but was:<103> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutAsync(AbstractRemoteCacheIT.java:574) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4813) JMX returns wrong number of cache entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4813?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-4813: -------------------------------------- Assignee: Galder Zamarreño > JMX returns wrong number of cache entries > ----------------------------------------- > > Key: ISPN-4813 > URL: https://issues.jboss.org/browse/ISPN-4813 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Remote Protocols, Server > Reporter: Vojtech Juranek > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > Number of cache entries ({{numberOfEntries}}) provided by JMX is wrong. {{HotRodRemoteCacheIT#testPutAsyc}} fails with assert error (see bellow), because JMX returns wrong number of entries in the cache. When debugging the test, number of entries in the cache is correct (100 - obrained e.g. by {{cache.getBulk().size()}}), but JMX return wrong number (100). Even on cleared cache JMX return that it contains 3 entries. When the {{clear}} operation is called via JMX, JMX show correct number (0). > {noformat} > java.lang.AssertionError: expected:<100> but was:<103> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutAsync(AbstractRemoteCacheIT.java:574) > {noformat} -- 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 updated ISPN-4852: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155606 > 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 updated ISPN-4856: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155602 > 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-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: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1152886|https://bugzilla.redhat.com/show_bug.cgi?id=1152886] from NEW to POST > 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-4776) The topology id for the merged cache topology is not always bigger than all the partition topology ids

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4776: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Final Resolution: Done > 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.Final, 7.0.0.CR2 > > > 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-4783) Using new ArrayList<>(resultCache.values())

by Markus Vogt (JIRA)

[ https://issues.jboss.org/browse/ISPN-4783?page=com.atlassian.jira.plugin.... ] Markus Vogt commented on ISPN-4783: ----------------------------------- Hi Dan, i've added the test class to this issue. The config files is attached to. I'm using a SingleFileStore. Regard, Markus > Using new ArrayList<>(resultCache.values()) > ------------------------------------------- > > Key: ISPN-4783 > URL: https://issues.jboss.org/browse/ISPN-4783 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Markus Vogt > Attachments: cacheConfig.xml, ISPN4783_Test.java > > > Hi, > I am a little bit confused about the behaviour of getting the values from a cache and inserting into an ArrayList. > I've putted one value into a cache, so that cache.size() is returning 1. If i now use 'new ArrayList<>(resultCache.values())', there will be two items in the list. > By iterating over the cache, only one iteration will run... Where comes the second item from? > Regards, > Markus -- 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