January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4034) Cache RPCs should not wait for replies from nodes that have not joined the cache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4034?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4034: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Cache RPCs should not wait for replies from nodes that have not joined the cache > -------------------------------------------------------------------------------- > > Key: ISPN-4034 > URL: https://issues.jboss.org/browse/ISPN-4034 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: 630 > Fix For: 7.1.0.CR1 > > > In a replicated cache, commands are broadcasted to the entire cluster and the originator waits for some kind of response from all the nodes in the cluster, even they are not members of the cache. > If a node doesn't have Infinispan's RpcDispatcher installed, it will never send any response, and replicated cache operations on the other nodes will all time out. See MissingRpcDispatcherTest for an example. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4039) DistSyncTxFuncTest and its subclasses fail all the time

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4039?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4039: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > DistSyncTxFuncTest and its subclasses fail all the time > ------------------------------------------------------- > > Key: ISPN-4039 > URL: https://issues.jboss.org/browse/ISPN-4039 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 7.1.0.CR1 > > > All the methods in DistSyncTxFuncTest and its subclasses DistAsyncTxFuncTest, DistSyncTxUnsafeFuncTest, DistAsyncTxUnsafeFuncTest, fail in TeamCity. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4019) Write a test with a node joining/leaving during a map/reduce task

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4019?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4019: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Write a test with a node joining/leaving during a map/reduce task > ----------------------------------------------------------------- > > Key: ISPN-4019 > URL: https://issues.jboss.org/browse/ISPN-4019 > Project: Infinispan > Issue Type: Task > Components: Distributed Execution and Map/Reduce, Test Suite - Core > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > We should have a test to confirm that the M/R results do not change if a node joins/leaves during each of the map/combine/distributed reduce phases. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4033) ConcurrentInterceptorVisibilityTest.testGetVisibility random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4033?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4033: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > ConcurrentInterceptorVisibilityTest.testGetVisibility random failures > --------------------------------------------------------------------- > > Key: ISPN-4033 > URL: https://issues.jboss.org/browse/ISPN-4033 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 7.1.0.CR1 > > Attachments: ConcurrentInterceptorVisibilityTest.log > > > http://ci.infinispan.org/viewLog.html?buildId=5934&tab=buildResultsDiv&bu... > {noformat} > 17:28:43,212 ERROR (testng-ConcurrentInterceptorVisibilityTest:) [UnitTestTestNGListener] Test testGetVisibility(org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest) failed. > java.lang.RuntimeException: java.util.concurrent.TimeoutException > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest$1.call(ConcurrentInterceptorVisibilityTest.java:101) > at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1243) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest.updateCache(ConcurrentInterceptorVisibilityTest.java:52) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest.testGetVisibility(ConcurrentInterceptorVisibilityTest.java:39) > Caused by: java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) > at java.util.concurrent.FutureTask.get(FutureTask.java:91) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest$1.call(ConcurrentInterceptorVisibilityTest.java:97) > ... 24 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4044) OngoingTransactionsAndJoinTest.testRehashOnJoin always fails

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4044?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4044: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > OngoingTransactionsAndJoinTest.testRehashOnJoin always fails > ------------------------------------------------------------ > > Key: ISPN-4044 > URL: https://issues.jboss.org/browse/ISPN-4044 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 7.1.0.CR1 > > > http://ci.infinispan.org/viewLog.html?buildId=6695&tab=buildResultsDiv&bu... > {noformat} > org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216) > at org.infinispan.CacheImpl.start(CacheImpl.java:674) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:371) > at org.infinispan.test.MultipleCacheManagersTest.cache(MultipleCacheManagersTest.java:372) > at org.infinispan.distribution.rehash.OngoingTransactionsAndJoinTest.testRehashOnJoin(OngoingTransactionsAndJoinTest.java:114) > Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache ___defaultcache on OngoingTransactionsAndJoinTest-NodeB-8681 > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:209) > at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4020) Write a test for map/reduce with passivation enabled

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4020?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4020: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Write a test for map/reduce with passivation enabled > ---------------------------------------------------- > > Key: ISPN-4020 > URL: https://issues.jboss.org/browse/ISPN-4020 > Project: Infinispan > Issue Type: Task > Components: Distributed Execution and Map/Reduce, Test Suite - Core > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > If an entry is activated (i.e. removed from the store) during the mapping phase, between the iteration of the data container and the iteration of the cache store, it may be possible for that entry to be skipped. We need to write a test to confirm if this is the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4075: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > State transfer should preserve the creation timestamp of entries > ---------------------------------------------------------------- > > Key: ISPN-4075 > URL: https://issues.jboss.org/browse/ISPN-4075 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended. > The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4032) Listeners on originator node in DIST are notified even when not an owner

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4032?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4032: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Listeners on originator node in DIST are notified even when not an owner > ------------------------------------------------------------------------ > > Key: ISPN-4032 > URL: https://issues.jboss.org/browse/ISPN-4032 > Project: Infinispan > Issue Type: Bug > Components: Core, Listeners > Affects Versions: 6.0.1.Final > Reporter: William Burns > Labels: 630 > Fix For: 7.1.0.CR1 > > > Currently we notify listeners installed on the originator node when they perform a write command. This is done even when the originator node doesn't own the key. These notifications should only be fired by primary owner/backup owners normally and only primary if configured to do so. > The DistListenerTest currently even asserts this behavior around line ~85. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4175) Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4175?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4175: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4175 > URL: https://issues.jboss.org/browse/ISPN-4175 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.1.0.CR1 > > > {code} > 11:47:01,852 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.infinispan.clustered.memcachedCache: org.jboss.msc.service.StartException in service jboss.infinispan.clustered.memcachedCache: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:546) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:517) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:399) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:413) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > ... 3 more > Caused by: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true > at org.infinispan.factories.AbstractComponentRegistry.throwStackAwareConfigurationException(AbstractComponentRegistry.java:884) > at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:299) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:270) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227) > at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65) > at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797) > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:148) > at org.infinispan.query.remote.LifecycleManager.initProtobufMetadataManager(LifecycleManager.java:56) > at org.infinispan.query.remote.LifecycleManager.cacheManagerStarted(LifecycleManager.java:70) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228) > ... 12 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4190: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList > ------------------------------------------------------------------------- > > Key: ISPN-4190 > URL: https://issues.jboss.org/browse/ISPN-4190 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.0.0.Alpha2 > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self. > JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 January 2015