November 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2574: --------------------------------- Summary: Segment transfer not restarted if the owner fails Key: ISPN-2574 URL: https://issues.jboss.org/browse/ISPN-2574 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta4 Reporter: Radim Vansa Assignee: Adrian Nistor Priority: Critical Imagine this situation in distributed cache with 3 owners: 1) The segment X is owned by nodes A, B, C 2) Node B fails -> CH_UPDATE and then REBALANCE_START are transfered 3) Node D starts transfer of segment X from C 4) Node C fails -> another CH update is transfered 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

6
11
0 / 0

[JBoss JIRA] (ISPN-2257) SimpleCacheRecoveryAdminTest.testForceCommitOnOtherNode still randomly failing

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2257: -------------------------------------- Summary: SimpleCacheRecoveryAdminTest.testForceCommitOnOtherNode still randomly failing Key: ISPN-2257 URL: https://issues.jboss.org/browse/ISPN-2257 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.2.0.Alpha4 The issue is failing again in master: {code}Failed tests: testForceCommitOnOtherNode(org.infinispan.tx.recovery.admin.SimpleCacheRecoveryAdminTest): expected:<false> but was:<true>{code} Unfortunately I don't have any logs. No idea if this is related to NBST at all :( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
6
0 / 0

[JBoss JIRA] (ISPN-2541) MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2541: -------------------------------------- Summary: MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly Key: ISPN-2541 URL: https://issues.jboss.org/browse/ISPN-2541 Project: Infinispan Issue Type: Bug Components: Marshalling Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.CR1 {code}Failed tests: testReplicateJBossExternalizePojoToNewJoiningNode(org.infinispan.marshall.MarshallExternalPojosTest): Replication timeout for MarshallExternalPojosTest-NodeC-10724{code} TRACE log: https://dl.dropbox.com/u/6148072/testReplicateJBossExternalizePojoToNewJo... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-928) Interceptor that allows invocations only when cluster is formed of N nodes

by Galder Zamarreño (JIRA)

Interceptor that allows invocations only when cluster is formed of N nodes -------------------------------------------------------------------------- Key: ISPN-928 URL: https://issues.jboss.org/browse/ISPN-928 Project: Infinispan Issue Type: Feature Request Components: Configuration, RPC Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final Following from https://github.com/pmuir/infinispan-examples/commit/f5d090092fa7b3660025b... It'd be great to have an configurable StrictCluster interceptor in Infinispan which would basically make all invocations wait until the cluster of N nodes has been formed. I think it'd be a great addition and would allow clients to verify whether the cluster actually forms without the need to verify whether data replicates...etc. In principle, the configuration would be at the CacheManager, i.e.: <transport strictNumMembers="4"... /> However, it could also be useful to configure it at the cache level. So, could maybe want to do this: I want cache X to allow invocations the moment I have 2 nodes (in spite of the cluster being formed of 4 noes), whereas I want cache Y to allow invocations once I have 3 nodes. Apart from an strict number of nodes, you could have a minimum number of nodes: allow invocations once I have 4 or more nodes. The strict value could still be useful to make sure intrusive machines don't get into the cluster, i.e. I expect 4 nodes in the cluster and if I have 5, something is wrong. I think it's an interesting concept that would get rid of cluster validation code in examples and RadarGun. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
4
0 / 0

[JBoss JIRA] (ISPN-2511) org.infinispan.remoting.RemoteExceptionHandlingWithStateTransferTest.testThrowExceptionFromRemoteInterceptor fails randomly

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-2511: ----------------------------------- Summary: org.infinispan.remoting.RemoteExceptionHandlingWithStateTransferTest.testThrowExceptionFromRemoteInterceptor fails randomly Key: ISPN-2511 URL: https://issues.jboss.org/browse/ISPN-2511 Project: Infinispan Issue Type: Bug Reporter: Anna Manukyan Assignee: Mircea Markus https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... The test works properly, when run separately. More logs will be provided later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
11
0 / 0

[JBoss JIRA] (ISPN-2572) "CacheException: Initial state transfer timed out for cache" reliably on AS7 testsuite

by Radoslav Husar (JIRA)

Radoslav Husar created ISPN-2572: ------------------------------------ Summary: "CacheException: Initial state transfer timed out for cache" reliably on AS7 testsuite Key: ISPN-2572 URL: https://issues.jboss.org/browse/ISPN-2572 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta4 Reporter: Radoslav Husar Assignee: Dan Berindei Priority: Blocker Fix For: 5.2.0.CR1 While running AS7 testsuite with speedups implemented in my branch (https://github.com/jbossas/jboss-as/pull/3381) we are contantly seeing (log below) on Windows 2008. Run: http://teamcity.cafe-babe.org/viewLog.html?buildId=1689&tab=buildResultsD... {code} 16:34:46,092 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 13) MSC00001: Failed to start service jboss.infinispan.ejb.remote-connector-client-mappings: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.remote-connector-client-mappings: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:87) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_32] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] Caused by: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546) at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:199) at org.infinispan.CacheImpl.start(CacheImpl.java:520) at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:690) at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:653) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:563) at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:107) at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:98) at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78) at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:82) ... 4 more Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache remote-connector-client-mappings on node-1/ejb at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:209) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_32] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_32] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_32] at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_32] at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) ... 18 more {code} Affected version -- current master (say 7dc531002539b078e429418d8ef204e401beafd1). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
7
0 / 0

[JBoss JIRA] (ISPN-2453) Locks not cleaned up - timeouts on write operations after contention is over

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2453: ------------------------------------- Summary: Locks not cleaned up - timeouts on write operations after contention is over Key: ISPN-2453 URL: https://issues.jboss.org/browse/ISPN-2453 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Blocker Fix For: 5.2.0.Beta3 By artificially creating contention on a write operation which needs to be serialized among different threads, we get timeout exceptions of "could not acquire lock after 10 seconds" even if the contention happens very briefly and then the pending writer is given all the time without other threads disturbing it. Created a stresstest to show it: ReplaceOperationStressTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
5
0 / 0

[JBoss JIRA] (ISPN-2564) Scope views to caches rather than entire cluster

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-2564: ----------------------------------------- Summary: Scope views to caches rather than entire cluster Key: ISPN-2564 URL: https://issues.jboss.org/browse/ISPN-2564 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.2.0.Beta4 Reporter: Vladimir Blagojevic Assignee: Dan Berindei Fix For: 5.2.0.CR1, 5.2.0.Final Currently our codebase relies on the cache views to be equal to entire cluster, however, this might not be the case due to asymmetric cluster; certain cache instances running only on particular Infinispan nodes. We have to make sure that cache views, if needed are scoped properly to particular cache rather than entire cluster -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
7
0 / 0

[JBoss JIRA] (ISPN-2524) CLI: automatic key wrapping when dealing with caches used by HotRod

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2524: ------------------------------------- Summary: CLI: automatic key wrapping when dealing with caches used by HotRod Key: ISPN-2524 URL: https://issues.jboss.org/browse/ISPN-2524 Project: Infinispan Issue Type: Feature Request Components: CLI Affects Versions: 5.2.0.Beta3 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
1
0 / 0

[JBoss JIRA] (ISPN-2255) FineGrainedAtomicMap missing key, value pairs in some cluster nodes in distributed mode, embedded infinispan cache

by Zdenek Henek (JIRA)

Zdenek Henek created ISPN-2255: ---------------------------------- Summary: FineGrainedAtomicMap missing key,value pairs in some cluster nodes in distributed mode, embedded infinispan cache Key: ISPN-2255 URL: https://issues.jboss.org/browse/ISPN-2255 Project: Infinispan Issue Type: Feature Request Components: Fine-grained API Affects Versions: 5.1.5.FINAL Environment: Details about cluster: 1. Infinispan 5.1.5 2. java 7u5 64bit 3. linux 64bit (two nodes debian and one node ubuntu) 4. tomcat 7.0.28 5. jbossTM 4.16.0 JTA only Tomcat integration code is here: https://github.com/zvrablik/tomcatInfinispanSessionManager/tree/master/to... 6. all machines are on real hw ( no virtual machines), date and time is synchronized and shouldn't vary more than 1 second Reporter: Zdenek Henek Assignee: Mircea Markus I am using FineGrainedAtomicMap to store data into clustering distributed cache. When clustering set to replicated doesn't cause any issues or at least I haven't run into any. When I switch to distributed mode I don't see some key,value pairs in some nodes. This happens randomly. The numOwners is set to two and I have cluster of three nodes. more details: https://community.jboss.org/thread/203420?tstart=60 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2012