October 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2399) CacheManager.startCaches very slow when multiple caches are passed in

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2399: ----------------------------------- Summary: CacheManager.startCaches very slow when multiple caches are passed in Key: ISPN-2399 URL: https://issues.jboss.org/browse/ISPN-2399 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.2.0.Beta1, 6.0.0.Final Reporter: Mircea Markus Assignee: Mircea Markus the TransactionsSpanningReplicatedCachesTest uses the following code to start multiple caches: {code:java} cm1.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME); 63 cm2.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME); 64 waitForClusterToForm("c1", "c2", "cache1", "cache2"); {code} On my machine(MBP) this executes in 12 mins.The functionally equivalent below executes in 15 secs: {code:java} private void startAllCaches() { startCache("c1"); startCache("c2"); startCache("cache1"); startCache("cache2"); startCache(CacheContainer.DEFAULT_CACHE_NAME); } private void startCache(String c1) { cm1.getCache(c1); cm2.getCache(c1); waitForClusterToForm(c1); } {code} We need to analyse why this takes so long and also updated the test to use the CacheManagers.startCaches.. -- 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 months

1
3
0 / 0

[JBoss JIRA] (ISPN-2392) Optimize locking behaviour in non-transactional caches

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2392: ---------------------------------- Summary: Optimize locking behaviour in non-transactional caches Key: ISPN-2392 URL: https://issues.jboss.org/browse/ISPN-2392 Project: Infinispan Issue Type: Enhancement Components: Locking and Concurrency Affects Versions: 5.2.0.Beta1 Reporter: Thomas Fromm Assignee: Mircea Markus Situation: REPL_SYNC cache, non transactional, locking isolation level NONE Problem: when multiple threads trying to write same key on multiple nodes, the operation ends up mostly in locking timeouts Mircea mentioned that the locking behaviour for non-tx caches could be optimized as well as for tx-caches or use the same mechanisms. -- 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 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2395) Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping

by Nicolas Filotto (JIRA)

Nicolas Filotto created ISPN-2395: ------------------------------------- Summary: Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping Key: ISPN-2395 URL: https://issues.jboss.org/browse/ISPN-2395 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.2.0.Beta1, 5.1.7.Final, 5.1.6.FINAL, 5.1.5.FINAL Reporter: Nicolas Filotto Assignee: Mircea Markus Attachments: TestLocking.java In ISPN 5.0, you provided a workaround allowing us to sort the keys ourself in order to prevent deadlocks even in case we enable the lock striping (more details here ISPN-993), thanks to this workaround we could write a simple key comparator (that works with lock striping enabled or not) as next: {code} public int compare(Object k1, Object k2) { LockManager lm = cache.getLockManager(); int result = lm.getLockId(key1) - lm.getLockId(k2); } {code} Starting from ISPN 5.1 (ISPN-1132), the keys are sorted automatically by ISPN however unfortunately what has been done is incompatible with lock striping, indeed the keys are sorted regardless the lock distribution which is a mistake since we actually expect the keys to be sorted according to the corresponding locks and not to the keys themselves otherwise deadlock can still occur. As attached file, you will find a test case that shows the issue. -- 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 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2249) Fix test failures introduced with NBST

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2249: ----------------------------------- Summary: Fix test failures introduced with NBST Key: ISPN-2249 URL: https://issues.jboss.org/browse/ISPN-2249 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.Alpha4 -- 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 months

4
18
0 / 0

[JBoss JIRA] (ISPN-2388) CharSequence get converted to ChannelBuffer without explicit Charset

by Norman Maurer (JIRA)

Norman Maurer created ISPN-2388: ----------------------------------- Summary: CharSequence get converted to ChannelBuffer without explicit Charset Key: ISPN-2388 URL: https://issues.jboss.org/browse/ISPN-2388 Project: Infinispan Issue Type: Bug Reporter: Norman Maurer Assignee: Mircea Markus There are a few places in infinispan where a CharSequence is converted to a ChannelBuffer. This is done without an explicit Charset given, and so depends on the default Charset of the Platform. This should be fixed by use UTF_8 everywhere. -- 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 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2372) Memory leak in AbstractJBossMarshaller

by Marko Lukša (JIRA)

Marko Lukša created ISPN-2372: --------------------------------- Summary: Memory leak in AbstractJBossMarshaller Key: ISPN-2372 URL: https://issues.jboss.org/browse/ISPN-2372 Project: Infinispan Issue Type: Bug Affects Versions: 5.2.0.Beta1 Reporter: Marko Lukša Assignee: Mircea Markus {{AbstractJBossMarshaller.marshallerTL}} is leaking {{PerThreadInstanceHolder}} instances. These hold a reference to {{MarshallingConfiguration}}, which indirectly holds a reference to the classloader, which of course holds a truckload of stuff. The cause of the leak is the fact that noone ever calls {{remove()}} on {{marshallerTL}}. I've tried adding {{marshallerTL.remove()}} to {{AbstractJBossMarshaller.stop()}}, but this only removed references from JBossAS' MSC Service threads. Other threads (in my case only one thread - "http-/127.0.0.1:8080-2") are still causing the leak. Here's the complete path from Thread to ModuleClassLoader: {code} classes of org.jboss.modules.ModuleClassLoader value of java.util.Hashtable$Entry [4] of java.util.Hashtable$Entry[23] table of org.infinispan.util.Immutables$ImmutableTypedProperties configurationProperties of org.hibernate.search.impl.ImmutableSearchFactory delegate of org.hibernate.search.impl.MutableSearchFactory" searchFactoryImplementor of org.infinispan.query.CommandInitializer value of java.util.HashMap$Entry [0] of java.util.HashMap$Entry[4] table of java.util.HashMap commandInitializers of org.infinispan.util.ModuleProperties moduleProperties of org.infinispan.factories.GlobalComponentRegistry gcr of org.infinispan.marshall.jboss.ExternalizerTable objectTable of org.jboss.marshalling.MarshallingConfiguration configuration of org.infinispan.marshall.jboss.AbstractJBossMarshaller$PerThreadInstanceHolder value of java.lang.ThreadLocal$ThreadLocalMap$Entry [3462] of java.lang.ThreadLocal$ThreadLocalMap$Entry[4096] table of java.lang.ThreadLocal$ThreadLocalMap threadLocals of java.lang.Thread [Stack Local, Thread] ""http-/127.0.0.1:8080-2"" native ID: 0x1B18", "28" {code} -- 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 months

5
18
0 / 0

[JBoss JIRA] (ISPN-2393) Upgrade to JGroups 3.2.0.CR1

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2393: ----------------------------------- Summary: Upgrade to JGroups 3.2.0.CR1 Key: ISPN-2393 URL: https://issues.jboss.org/browse/ISPN-2393 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.2.0.Beta1 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.CR1 -- 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 months

1
1
0 / 0

[JBoss JIRA] (ISPN-2382) Transaction boundary commands are not forwarded during state transfer

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2382: ----------------------------------- Summary: Transaction boundary commands are not forwarded during state transfer Key: ISPN-2382 URL: https://issues.jboss.org/browse/ISPN-2382 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.2.0.Beta1 Reporter: Mircea Markus Assignee: Mircea Markus Priority: Critical Fix For: 5.2.0.CR1 Two issues: 1. StateTransferInterceptor.handleTxCommand, when invoking handleTopologyAffectedCommand internally, wrongly calculates the 2nd param of the invocation 2. StateTransferInterceptor.handleTopologyAffectedCommand This logic filters out commands that should be forwarded (e.g. late commands that happened before state transfer completed): {code:java} if (pendingCh != null && cmdTopologyId < localTopologyId + 1) { ConsistentHash writeCh = cacheTopology.getWriteConsistentHash(); Set<Object> affectedKeys = getAffectedKeys(ctx, command); Set<Address> newTargets = writeCh.locateAllOwners(affectedKeys); newTargets.remove(rpcManager.getAddress()); if (!newTargets.isEmpty()) { // Update the topology id to prevent cycles command.setTopologyId(localTopologyId); log.tracef("Forwarding command %s to new targets %s", command, newTargets); // TODO find a way to forward the command async if it was received async rpcManager.invokeRemotely(newTargets, command, true, false); } } {code} The if above should be removed. -- 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 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2301) DefaultConsistentHash does not use group annotation.

by Erik Salter (JIRA)

Erik Salter created ISPN-2301: --------------------------------- Summary: DefaultConsistentHash does not use group annotation. Key: ISPN-2301 URL: https://issues.jboss.org/browse/ISPN-2301 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.2.0.Alpha3 Reporter: Erik Salter Assignee: Mircea Markus Part of my design pattern is to use the Group API to group like-minded keys to the same segment. The DefaultConsistentHash impl, in returning the primary owner of a key, uses the key's hash code instead of the Group annotation value. According to TRACE logs, this results in remote LockControlCommand. See the comments for ISPN-2291 for logs associated with such keys. (These keys use "edgeDeviceId=" as the group value. -- 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 months

5
7
0 / 0

[JBoss JIRA] (ISPN-2385) ReceiveBufferSize has no effect

by Norman Maurer (JIRA)

Norman Maurer created ISPN-2385: ----------------------------------- Summary: ReceiveBufferSize has no effect Key: ISPN-2385 URL: https://issues.jboss.org/browse/ISPN-2385 Project: Infinispan Issue Type: Bug Affects Versions: 5.2.0.Beta1 Reporter: Norman Maurer Assignee: Mircea Markus -- 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 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012