February 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-922) Flags not being sent along with RpcCommands fail to affect remote InvocationContext

by Sanne Grinovero (JIRA)

Flags not being sent along with RpcCommands fail to affect remote InvocationContext ----------------------------------------------------------------------------------- Key: ISPN-922 URL: https://issues.jboss.org/browse/ISPN-922 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency, RPC Affects Versions: 4.2.0.Final, 4.1.0.Final, 4.0.0.Final Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.2.1.Final, 5.0.0.ALPHA3 Using the following sequence, using REPL_SYNC: [thread-A] nodeOne.put(K1, V1); [thread-B] nodeTwo.startBatch(); [thread-B] nodeTwo.remove(K1); [thread-A] nodeOne.withFlags(Flag.SKIP_LOCKING).remove(K1); At the last line, thread-B is blocked waiting to end the batch to after thread-A finished. This results in thread-A to throw a "org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [500 milliseconds] on key" Still if I run the same sequence of operation on two different threads on the same node, this will work just fine and not throw any error: [thread-A] nodeOne.put(K1, V1); [thread-B] nodeOne.startBatch(); [thread-B] nodeOne.remove(K1); [thread-A] nodeOne.withFlags(Flag.SKIP_LOCKING).remove(K1); Looking into org.infinispan.interceptors.ReplicationInterceptor.handleCrudMethod(InvocationContext, WriteCommand), it seems that any Flag is not sent to remove nodes. Actually the whole org.infinispan.remoting.rpc.RpcManager interface is not interested in Flags. Test being send soon to GitHub. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
12
0 / 0

[JBoss JIRA] Created: (ISPN-933) Centralize all usages of System.identifyHashCode()

by Galder Zamarreño (JIRA)

Centralize all usages of System.identifyHashCode() -------------------------------------------------- Key: ISPN-933 URL: https://issues.jboss.org/browse/ISPN-933 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 4.2.1.CR2, 5.0.0.ALPHA3 Substitute all uses of System.identityHashCode() behind a method like this in Util: public static String hexIdHashCode(Object o) { return Integer.toHexString(System.identityHashCode(o)); } The hexadecimal version occupies less space and does the same job. Also, stop/start marshaller should not print the id hash code, it's too verbose and it's only needed when debugging a particular problem which has not been present in a while. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-925) race condition in DistributionManagerImpl

by Mircea Markus (JIRA)

race condition in DistributionManagerImpl ----------------------------------------- Key: ISPN-925 URL: https://issues.jboss.org/browse/ISPN-925 Project: Infinispan Issue Type: Bug Components: Core API, State transfer Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Priority: Critical Fix For: 4.2.1.Final, 5.0.0.ALPHA3, 5.0.0.Final This is causing StateTransferLargeObjectTest to fail intermittently (about 1/500 runs). Nasty race condition in DistributionManagerImpl 1. if a node leaves then the new consistent hash is first set ( consistentHash = ConsistentHashHelper.removeAddress(consistentHash, leaver, configuration, topologyInfo);) 2. then an InvertedLeaveTask is triggered if needed 3 this would add the leaver to DMI.levers and set the rehashInProgress flag of DMImpl to true (RehashTask.call) Now if a get call happens between 1 and 3 then then the the system would not go remotley. The "go remotly if there's a rehash going on" condition happens in DistInterceptor.visitGetKeyValueCommand: boolean isRehashInProgress = !dm.isJoinComplete() || dm.isRehashInProgress(); if the isRehashInProgress is set to true then we go remotly even if the key is mapped to the local node. Nasty! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-886) Support running a transaction from multiple threads at the same time

by Mircea Markus (JIRA)

Support running a transaction from multiple threads at the same time ---------------------------------------------------------------------- Key: ISPN-886 URL: https://issues.jboss.org/browse/ISPN-886 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 6.0.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Priority: Optional running a tx from multiple threads is not clearly defined by the spec but supported by certain TMs (e.g. JBossTM) and can be very useful for transactions for which the work can be parallelised. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-851) Locate Marshaller implementation using helper methods

by Galder Zamarreño (JIRA)

Locate Marshaller implementation using helper methods ----------------------------------------------------- Key: ISPN-851 URL: https://issues.jboss.org/browse/ISPN-851 Project: Infinispan Issue Type: Task Components: Marshalling Affects Versions: 5.0.0.ALPHA1, 4.2.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1 Use: Marshaller.getMarshallerFactory("river"); Instead of: (MarshallerFactory) Thread.currentThread().getContextClassLoader().loadClass("org.jboss.marshalling.river.RiverMarshallerFactory").newInstance(); -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
11
0 / 0

[JBoss JIRA] Created: (ISPN-885) Murmurhash3.hash(long[]) infinitely recurses because its static

by Patrick McFarland (JIRA)

Murmurhash3.hash(long[]) infinitely recurses because its static --------------------------------------------------------------- Key: ISPN-885 URL: https://issues.jboss.org/browse/ISPN-885 Project: Infinispan Issue Type: Bug Components: Distributed Cache Reporter: Patrick McFarland Assignee: Manik Surtani Fixed in my t_mmh3 branch, https://github.com/infinispan/infinispan/pull/130 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-884) @MergeView not working

by Mircea Markus (JIRA)

@MergeView not working ---------------------- Key: ISPN-884 URL: https://issues.jboss.org/browse/ISPN-884 Project: Infinispan Issue Type: Bug Reporter: Mircea Markus Assignee: Manik Surtani and there's no UT to check this functionality -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-894) Upgrade to JGroups 2.12.0.CR1

by Galder Zamarreño (JIRA)

Upgrade to JGroups 2.12.0.CR1 ----------------------------- Key: ISPN-894 URL: https://issues.jboss.org/browse/ISPN-894 Project: Infinispan Issue Type: Thirdparty Change Components: RPC Reporter: Galder Zamarreño Assignee: Vladimir Blagojevic Fix For: 5.0.0.BETA1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-889) Remove JBoss Common Core dependency

by Galder Zamarreño (JIRA)

Remove JBoss Common Core dependency ----------------------------------- Key: ISPN-889 URL: https://issues.jboss.org/browse/ISPN-889 Project: Infinispan Issue Type: Thirdparty Change Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.1.Final, 5.0.0.BETA1 Looking at Infinispan's dependencies, core seems to depend on JBoss Common Core simply to take advantage of org.jboss.util.StringPropertyReplacer. Test code also depends for org.jboss.util.naming.NonSerializableFactory. What about we make our own org.jboss.util.StringPropertyReplacer and remove JBoss Common Core from being a main dependency? We could still keep it as a test dependency for org.jboss.util.naming.NonSerializableFactory. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-900) RemoteCache should implement size() and isEmpty()

by Galder Zamarreño (JIRA)

RemoteCache should implement size() and isEmpty() ------------------------------------------------- Key: ISPN-900 URL: https://issues.jboss.org/browse/ISPN-900 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.1.Final, 5.0.0.BETA1 It's dead easy to do this by simply checking the stats returned by the server, i.e. @Override public int size() { assertRemoteCacheManagerIsStarted(); StatsOperation op = operationsFactory.newStatsOperation(); return Integer.parseInt(((Map<String, String>) op.execute()).get(ServerStatistics.CURRENT_NR_OF_ENTRIES)); } @Override public boolean isEmpty() { return size() == 0; } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2011