October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4872) A pessimistic transaction can fail due to a ClusteredGetCommand forcing a lock command

by Erik Salter (JIRA)

Erik Salter created ISPN-4872: --------------------------------- Summary: A pessimistic transaction can fail due to a ClusteredGetCommand forcing a lock command Key: ISPN-4872 URL: https://issues.jboss.org/browse/ISPN-4872 Project: Infinispan Issue Type: Bug Reporter: Erik Salter -- 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 Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4783?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4783: ------------------------------------ Markus, what kind of cache is it? Can you attach the configuration (or even a runnable test, if you have it)? > 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 > > 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

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] Work on ISPN-4776 started by Dan Berindei. ------------------------------------------ > 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 > > > 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-4871) Remove KeyValueFilterFactory and ConverterFactory to prevent confusion

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4871?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4871: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove KeyValueFilterFactory and ConverterFactory to prevent confusion > ---------------------------------------------------------------------- > > Key: ISPN-4871 > URL: https://issues.jboss.org/browse/ISPN-4871 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > When ISPN-4753 was added we moved to CacheEventFilterFactory and CacheEventConverterFactory. Thinking about this more it is confusing to have both factories when the one is not used currently. We should remove it. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4795) Warning message about forcing to return previous does not apply to Get operations

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4795?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4795: ------------------------------------ We could also log the message only the first time the FORCE_RETURN_VALUE flag is applied on a non-transactional cache operation, we shouldn't try to force users to switch to transactional caches by filling their logs with warning messages. > Warning message about forcing to return previous does not apply to Get operations > --------------------------------------------------------------------------------- > > Key: ISPN-4795 > URL: https://issues.jboss.org/browse/ISPN-4795 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final > > > {code} > 'ISPN006010: Operation 'GetRequest' forced to return previous value should be used on transactional caches' in the log > {code} > That message should not appear. GetRequest does not force returning previous. -- 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 Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] Dan Berindei reopened ISPN-4776: -------------------------------- Forgot to update PreferAvailabilityStrategy as well... > 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 > > > 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-4869) RestStoreParallelIterationTest.clearContent random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4869?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4869: ------------------------------------ Test {{RestStoreParallelIterationTest.testParallelIterationWithoutValueOrMetadata}} also fails with the same error. > RestStoreParallelIterationTest.clearContent random failures > ----------------------------------------------------------- > > Key: ISPN-4869 > URL: https://issues.jboss.org/browse/ISPN-4869 > 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} > java.lang.RuntimeException: Could not retrieve HotRod host > at org.infinispan.arquillian.utils.MBeanUtils.getMBeanAttribute(MBeanUtils.java:59) > at org.infinispan.arquillian.core.HotRodEndpoint.getInetAddress(HotRodEndpoint.java:65) > at org.infinispan.server.test.util.ITestUtils.createCacheManager(ITestUtils.java:52) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createManager(RemoteCacheManagerFactory.java:50) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createCache(RemoteCacheManagerFactory.java:34) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createCache(RemoteCacheManagerFactory.java:30) > at org.infinispan.server.test.configs.ExampleConfigsIT.createCache(ExampleConfigsIT.java:726) > at org.infinispan.server.test.configs.ExampleConfigsIT.testXsiteConfig(ExampleConfigsIT.java:584) > Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Server,name=HotRod,component=Transport > at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1085) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:380) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetAttributeHandler.handle(ServerProxy.java:691) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:415) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > Failing only on the internal CI agents. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4869) RestStoreParallelIterationTest.clearContent random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4869?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4869: ------------------------------- Component/s: Server Test Suite - Server (was: Remote Protocols) (was: Core) (was: Test Suite - Core) > RestStoreParallelIterationTest.clearContent random failures > ----------------------------------------------------------- > > Key: ISPN-4869 > URL: https://issues.jboss.org/browse/ISPN-4869 > 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} > java.lang.RuntimeException: Could not retrieve HotRod host > at org.infinispan.arquillian.utils.MBeanUtils.getMBeanAttribute(MBeanUtils.java:59) > at org.infinispan.arquillian.core.HotRodEndpoint.getInetAddress(HotRodEndpoint.java:65) > at org.infinispan.server.test.util.ITestUtils.createCacheManager(ITestUtils.java:52) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createManager(RemoteCacheManagerFactory.java:50) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createCache(RemoteCacheManagerFactory.java:34) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createCache(RemoteCacheManagerFactory.java:30) > at org.infinispan.server.test.configs.ExampleConfigsIT.createCache(ExampleConfigsIT.java:726) > at org.infinispan.server.test.configs.ExampleConfigsIT.testXsiteConfig(ExampleConfigsIT.java:584) > Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Server,name=HotRod,component=Transport > at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1085) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:380) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetAttributeHandler.handle(ServerProxy.java:691) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:415) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > Failing only on the internal CI agents. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4166) useSynchronization should be disabled by default

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4166?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-4166: ---------------------------------- Assignee: Dan Berindei (was: Ion Savin) > useSynchronization should be disabled by default > ------------------------------------------------ > > Key: ISPN-4166 > URL: https://issues.jboss.org/browse/ISPN-4166 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Final > > > When Infinispan registers with the transaction manager as a synchronization, failures during commit are not reported to the user. > Even if registering as a synchronization is faster in some cases, the default should be the safe version. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4629) Clarify what happens when an available partition and a degraded mode partition merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4629?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-4629. -------------------------------- Fix Version/s: 7.0.0.CR2 (was: 7.0.0.Final) Resolution: Done The documentation actually describes how the data on the minority partition will be wiped and it will receive the state from the majority partition. There is also a test for this, ThreeWaySplitAndMergeTest. > Clarify what happens when an available partition and a degraded mode partition merge > ------------------------------------------------------------------------------------ > > Key: ISPN-4629 > URL: https://issues.jboss.org/browse/ISPN-4629 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Dan Berindei > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > I believe the implementation in https://github.com/infinispan/infinispan/pull/2785 clears the data in the degraded mode partition (since it could be stale) and then rebalances the data from the available partition on all nodes. > We should add a test to confirm and document it. -- 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