May 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-429) Make sure DefaultConsistentHash replicates addressToHashIds map

by Galder Zamarreno (JIRA)

Make sure DefaultConsistentHash replicates addressToHashIds map --------------------------------------------------------------- Key: ISPN-429 URL: https://jira.jboss.org/jira/browse/ISPN-429 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.1.0.BETA1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR1 addressToHashIds is not currently sent across to other nodes at replication time. Investigate the side effects of this and whether it's necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-428) Hashing generating recipient lists with same address

by Galder Zamarreno (JIRA)

Hashing generating recipient lists with same address ---------------------------------------------------- Key: ISPN-428 URL: https://jira.jboss.org/jira/browse/ISPN-428 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.1.0.BETA1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR1 Hi all, As indicated on IRC, running org.infinispan.client.hotrod.TopologyChangeTest.testTwoMembers() fails randomly with replication timeout. It's very easy to replicate. When it fails, this is what happens: 1. During rehashing, a new hash is installed: 2010-05-06 17:54:11,960 4932 TRACE [org.infinispan.distribution.DistributionManagerImpl] (Rehasher-eq-985:) Installing new consistent hash DefaultConsistentHash{addresses ={109=eq-35426, 10032=eq-985, 10033=eq-985}, hash space =10240} 2. Rehash finishes and the previous hash is still installed: 2010-05-06 17:54:11,978 4950 INFO [org.infinispan.distribution.JoinTask] (Rehasher-eq-985:) eq-985 completed join in 30 milliseconds! 3. A put comes in to eq-985 who decides recipients are [eq-985, eq-985]. Most likely, the hash falled somewhere between 109 and 10032 and since owners are 2, it took the next 2: 2010-05-06 17:54:12,307 5279 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (HotRodServerWorker-2-1:) eq-985 broadcasting call PutKeyValueCommand{key=CacheKey{data=ByteArray{size=9, hashCode=d28dfa, array=[-84, -19, 0, 5, 116, 0, 2, 107, 48, ..]}}, value=CacheValue{data=ByteArray{size=9, array=[-84, -19, 0, 5, 116, 0, 2, 118, 48, ..]}, version=281483566645249}, putIfAbsent=false, lifespanMillis=-1000, maxIdleTimeMillis=-1000} to recipient list [eq-985, eq-985] Everything afterwards is a mess: 4. JGroups removes the local address from the destination. The reason Infinispan does not do it it's because the number of recipients is 2 and the number of members in the cluster 2, so it thinks it's a broadcast: 2010-05-06 17:54:12,308 5280 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (HotRodServerWorker-2-1:) real_dests=[eq-985] 5. JGroups still sends it as a broadcast: 2010-05-06 17:54:12,308 5280 TRACE [org.jgroups.protocols.TCP] (HotRodServerWorker-2-1:) sending msg to null, src=eq-985, headers are RequestCorrelator: id=201, type=REQ, id=12, rsp_expected=true, NAKACK: [MSG, seqno=5], TCP: [channel_name=Infinispan-Cluster] 6. Another node deals with this and replies: 2010-05-06 17:54:12,310 5282 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-1,Infinispan-Cluster,eq-35426:) Attempting to execute command: SingleRpcCommand{cacheName='___defaultcache', command=PutKeyValueCommand{key=CacheKey{data=ByteArray{size=9, hashCode=43487e, array=[-84, -19, 0, 5, 116, 0, 2, 107, 48, ..]}}, value=CacheValue{data=ByteArray{size=9, array=[-84, -19, 0, 5, 116, 0, 2, 118, 48, ..]}, version=281483566645249}, putIfAbsent=false, lifespanMillis=-1000, maxIdleTimeMillis=-1000}} [sender=eq-985] ... 7. However, no replies yet from eq-985, so u get: 2010-05-06 17:54:27,310 20282 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (HotRodServerWorker-2-1:) responses: [sender=eq-985, retval=null, received=false, suspected=false] 2010-05-06 17:54:27,313 20285 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (HotRodServerWorker-2-1:) replication exception: org.infinispan.util.concurrent.TimeoutException: Replication timeout for eq-985 Now, I don't understand the reason for creating a hash 10032=eq-985, 10033=eq-985. Shouldn't keeping 10032=eq-985 be enough? Why add 10033=eq-985? Assuming there was a valid case for it, a naive approach would be to discard a second node that points to the an address already in the recipient list. So, 10032=eq-985 would be accepted for the list but when encountering 10033=eq-985, this would be skipped. Finally, I thought waiting for rehashing to finish would solve the issue but as u can see in 2., rehashing finished and the hash is still in the same shape. Also, I've attached a log file. Cheers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-423) Implement MurmurHash2 for hashing addresses and keys in the DefaultConsistentHash impl

by Manik Surtani (JIRA)

Implement MurmurHash2 for hashing addresses and keys in the DefaultConsistentHash impl -------------------------------------------------------------------------------------- Key: ISPN-423 URL: https://jira.jboss.org/jira/browse/ISPN-423 Project: Infinispan Issue Type: Task Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.Final This will provide a more even distribution with far fewer collissions and "clustering" of keys. It will also allow external non-Java systems to calculate the hashes of keys for smart Hot Rod clients. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-411) Implement hash distribution headers in Hot Rod

by Galder Zamarreno (JIRA)

Implement hash distribution headers in Hot Rod ---------------------------------------------- Key: ISPN-411 URL: https://jira.jboss.org/jira/browse/ISPN-411 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Implement Hash-Distribution-Aware Client Topology Change headers as per http://community.jboss.org/docs/DOC-14421 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-370) clear the store before state transfer

by Mircea Markus (JIRA)

clear the store before state transfer -------------------------------------- Key: ISPN-370 URL: https://jira.jboss.org/jira/browse/ISPN-370 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.0.1.CR1 Right now, before integrating state (fetch persistent state = true) the cacheStore.clear() is performed within cacheStore. This cacheStore.clear() should be moved outside the store, in StateTransferManager, and state transfer should document that the the store is cleared before integrating remote state. This is in relation to: http://lists.jboss.org/pipermail/infinispan-dev/2010-March/002483.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
3
0 / 0

[JBoss JIRA] Updated: (ISPN-186) Smart L1 cache invalidation

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-186?page=com.atlassian.jira.plugi... ] Manik Surtani updated ISPN-186: ------------------------------- Fix Version/s: 4.1.0.CR1 (was: 4.1.0.BETA1) > Smart L1 cache invalidation > --------------------------- > > Key: ISPN-186 > URL: https://jira.jboss.org/jira/browse/ISPN-186 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 4.1.0.CR1, 4.1.0.Final > > > Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners. > Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-180) Colocated nodes should be handled in DIST

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-180?page=com.atlassian.jira.plugi... ] Manik Surtani updated ISPN-180: ------------------------------- Fix Version/s: 4.1.0.CR1 (was: 4.1.0.BETA1) > Colocated nodes should be handled in DIST > ----------------------------------------- > > Key: ISPN-180 > URL: https://jira.jboss.org/jira/browse/ISPN-180 > Project: Infinispan > Issue Type: Feature Request > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 4.1.0.CR1, 4.1.0.Final > > > DefaultConsistentHash should place addresses on the hash wheel such that colocated nodes are never less than repl_count nodes apart to prevent data loss when a server fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-421) Web: Wrong link to Maven

by Ondrej Žižka (JIRA)

Web: Wrong link to Maven ------------------------ Key: ISPN-421 URL: https://jira.jboss.org/jira/browse/ISPN-421 Project: Infinispan Issue Type: Bug Affects Versions: 4.1.0.ALPHA3 Environment: http://www.jboss.org/infinispan/downloads.html Reporter: Ondrej Žižka Assignee: Manik Surtani Priority: Trivial http://www.jboss.org/infinispan/downloads.html - The "Maven Snapshots Repository" leads to a 404 at http://www.jboss.org/horizon/downloads.html#fromMaven -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-422) Configuration.setConsistentHashClass not working

by Galder Zamarreno (JIRA)

Configuration.setConsistentHashClass not working ------------------------------------------------ Key: ISPN-422 URL: https://jira.jboss.org/jira/browse/ISPN-422 Project: Infinispan Issue Type: Bug Components: Configuration, Distributed Cache Affects Versions: 4.1.0.ALPHA3, 4.0.0.Final Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Consistent class cannot be defined via configuration. Doing so throws: org.infinispan.CacheException: Could not apply value for field class from instance org.infinispan.config.Configuration$HashType@f449758d on instance org.infinispan.config.OverrideConfigurationVisitor@182a033 at org.infinispan.config.OverrideConfigurationVisitor.overrideFields(OverrideConfigurationVisitor.java:97) at org.infinispan.config.OverrideConfigurationVisitor.override(OverrideConfigurationVisitor.java:80) at org.infinispan.config.Configuration.applyOverrides(Configuration.java:156) at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:372) at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:342) at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:139) at org.infinispan.distribution.BaseDistFunctionalTest.createCacheManagers(BaseDistFunctionalTest.java:59) at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:56) at org.infinispan.test.MultipleCacheManagersTest.createBeforeClass(MultipleCacheManagersTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:90) at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:183) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:115) at org.testng.TestRunner.runWorkers(TestRunner.java:908) at org.testng.TestRunner.privateRun(TestRunner.java:617) at org.testng.TestRunner.run(TestRunner.java:498) at org.testng.SuiteRunner.runTest(SuiteRunner.java:329) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296) at org.testng.SuiteRunner.run(SuiteRunner.java:201) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:79) Caused by: org.infinispan.CacheException: Could not find field named: class on instance :org.infinispan.config.Configuration$HashType@f449758d at org.infinispan.util.ReflectionUtil.getValue(ReflectionUtil.java:204) at org.infinispan.config.OverrideConfigurationVisitor.overrideFields(OverrideConfigurationVisitor.java:95) ... 30 more This is because the field name provided to testImmutability call in setConsistentHashClass is "class". Hence, it tries to override a field called "class" which does not exist. Making the field "consistentHashClass" fixes the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-405) WebSocket Server

by Tom Fennelly (JIRA)

WebSocket Server ---------------- Key: ISPN-405 URL: https://jira.jboss.org/jira/browse/ISPN-405 Project: Infinispan Issue Type: Feature Request Reporter: Tom Fennelly Assignee: Manik Surtani Initial prototype: http://community.jboss.org/wiki/InfinispanWebSocketServer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2010