October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4688) Backport to 5.2.x for EAP 6.4

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-4688?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on ISPN-4688: -------------------------------------- Thanks for checking, nevermind then. I don't think we would need it rebased. (We might be, but the intuitive way is to check for known/fixed issues and this was one of the un-rebased ones.) > Backport to 5.2.x for EAP 6.4 > ----------------------------- > > Key: ISPN-4688 > URL: https://issues.jboss.org/browse/ISPN-4688 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 5.2.8.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.10.Final > > > Tracking jira for backporting fixes to 5.2.x for EAP 6.4. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4876) API for obtaining cache metadata

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4876: ------------------------------------- Summary: API for obtaining cache metadata Key: ISPN-4876 URL: https://issues.jboss.org/browse/ISPN-4876 Project: Infinispan Issue Type: Feature Request Reporter: Tristan Tarrant Currently we have a number of "service" caches which store additional information about "primary" caches (e.g. protobuf schemas, indexes, topology). We might also want to store other additional information (configurations, metadata, etc). I think we can hijack the ClusterRegistry class to provide a standardized interface to obtain "service" caches based on a set of requirements (persistent/volatile, shared/private, etc) and apply well-defined configurations to them (e.g. security). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4688) Backport to 5.2.x for EAP 6.4

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4688?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4688: ------------------------------------ [~rhusar], the ISPN-2255 fix looks very FGAHM-specific, because only FGAHM uses {{DeltaCompositeKey}}. Maybe you're hitting another bug in AHM? > Backport to 5.2.x for EAP 6.4 > ----------------------------- > > Key: ISPN-4688 > URL: https://issues.jboss.org/browse/ISPN-4688 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 5.2.8.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.10.Final > > > Tracking jira for backporting fixes to 5.2.x for EAP 6.4. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4688) Backport to 5.2.x for EAP 6.4

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-4688?page=com.atlassian.jira.plugin.... ] Radoslav Husar reopened ISPN-4688: ---------------------------------- Hi Dan, it looks like this ISPN-2255 is not exclusively related to FGAHM but also to AHM which we use in EAP. Could you please check and possibly rebase? > Backport to 5.2.x for EAP 6.4 > ----------------------------- > > Key: ISPN-4688 > URL: https://issues.jboss.org/browse/ISPN-4688 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 5.2.8.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.10.Final > > > Tracking jira for backporting fixes to 5.2.x for EAP 6.4. -- 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.... ] William Burns updated ISPN-4836: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2984 > 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 > Fix For: 7.0.0.Final > > > 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-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.... ] William Burns updated ISPN-4836: -------------------------------- Fix Version/s: 7.0.0.Final > 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 > Fix For: 7.0.0.Final > > > 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-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: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2985 > 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: ----------------------------------- Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015612.html > 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-4875) Integrate the RHQ Metrics collection and make it optional

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4875: ------------------------------------- Summary: Integrate the RHQ Metrics collection and make it optional Key: ISPN-4875 URL: https://issues.jboss.org/browse/ISPN-4875 Project: Infinispan Issue Type: Sub-task Components: JMX, reporting and management Reporter: Tristan Tarrant Priority: Minor -- 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: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1155611|https://bugzilla.redhat.com/show_bug.cgi?id=1155611] from ON_QA 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2014