July 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1757) Use a ConsistentHashFactory for consistent hash configuration

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1757: ---------------------------------- Summary: Use a ConsistentHashFactory for consistent hash configuration Key: ISPN-1757 URL: https://issues.jboss.org/browse/ISPN-1757 Project: Infinispan Issue Type: Task Reporter: Dan Berindei Assignee: Pete Muir The new programmatic configuration allows the user to configure a consistent hash with `HashConfigurationBuilder.consistentHash(ConsistentHash)`. Since we always create new instances of the consistent hash, I think it would be nicer if we had `HashConfigurationBuilder.consistentHashFactory(ConsistentHashFactory)` instead. This would also allow us to have a single default factory that can choose between creating a `DefaultconsistentHash` or a `TopologyAwareConsistentHash` based on the transport configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
3
0 / 0

[JBoss JIRA] (ISPN-1523) Remote nodes send duplicate invalidation messages

by Dan Berindei (Created) (JIRA)

Remote nodes send duplicate invalidation messages ------------------------------------------------- Key: ISPN-1523 URL: https://issues.jboss.org/browse/ISPN-1523 Project: Infinispan Issue Type: Bug Components: Distributed Cache Reporter: Dan Berindei Assignee: Manik Surtani I though only the originator should send invalidation messages, but I'm seeing these messages in the log: {noformat} 2011-11-11 11:10:27,608 TRACE (OOB-2,Infinispan-Cluster,NodeD-8993) [org.infinispan.interceptors.DistributionInterceptor] Put occuring on node, requesting cache invalidation for keys [k1]. Origin of command is remote 2011-11-11 11:10:27,608 TRACE (OOB-3,Infinispan-Cluster,NodeA-31187) [org.infinispan.interceptors.DistributionInterceptor] Put occuring on node, requesting cache invalidation for keys [k1]. Origin of command is remote 2011-11-11 11:10:27,608 TRACE (OOB-2,Infinispan-Cluster,NodeD-8993) [org.infinispan.distribution.L1ManagerImpl] Invalidating L1 caches for keys [k1] 2011-11-11 11:10:27,608 TRACE (OOB-3,Infinispan-Cluster,NodeA-31187) [org.infinispan.distribution.L1ManagerImpl] Invalidating L1 caches for keys [k1] {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

8
12
0 / 0

[JBoss JIRA] (ISPN-1856) Allow independent configuration of buffer allocation size vs segment chunks maximum size

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-1856: ------------------------------------- Summary: Allow independent configuration of buffer allocation size vs segment chunks maximum size Key: ISPN-1856 URL: https://issues.jboss.org/browse/ISPN-1856 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL Especially make sure that we can allocate buffers efficiently when having chunk_size=MAX_INTEGER or other very high values. Maybe reuse them as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
5
0 / 0

[JBoss JIRA] (ISPN-1748) Allow consistency for concurrent updates when syncCommitPhase=false

by Mircea Markus (JIRA)

Mircea Markus created ISPN-1748: ----------------------------------- Summary: Allow consistency for concurrent updates when syncCommitPhase=false Key: ISPN-1748 URL: https://issues.jboss.org/browse/ISPN-1748 Project: Infinispan Issue Type: Enhancement Components: Transactions Affects Versions: 5.1.0.CR4 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.FINAL when syncCommitPhase=false then there is a window of inconsistency in the case multipel tx access the same key at the same time. This can be avoided by sending the lock release command after the commit command, in the same thread which is async triggered by the TM.commit. This should be a very important performance buster for default configurations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
10
0 / 0

[JBoss JIRA] Created: (ISPN-820) Resolve {@link} links in configuration reference

by Galder Zamarreño (JIRA)

Resolve {@link} links in configuration reference ------------------------------------------------- Key: ISPN-820 URL: https://jira.jboss.org/browse/ISPN-820 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreño Assignee: Vladimir Blagojevic Fix For: 5.0.0.BETA1 Currently configuration reference documentation does not resolve {@link} links. It'd be nice if it'd point to the javadoc of the corresponding class if available! Examples: - Fully qualified class name of a class that looks up a reference to a {@link javax.transaction.TransactionManager}. The default provided is capable of locating the default TransactionManager in most popular Java EE systems, using a JNDI lookup. (Javadoc) - Fully qualified name of the class that the configured {@link org.infinispan.marshall.Externalizer} can marshall/unmarshall. Establishing the link between type marshalled and {@link org.infinispan.marshall.Externalizer} implementations enables users to provide their own marshalling mechanisms even for classes which they cannot modify or extend. (Javadoc) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

5
13
0 / 0

[JBoss JIRA] Created: (ISPN-1186) Document different approaches for working with cache statistics for local cache and remote cache (HotRod)

by Martin Gencur (JIRA)

Document different approaches for working with cache statistics for local cache and remote cache (HotRod) ---------------------------------------------------------------------------------------------------------- Key: ISPN-1186 URL: https://issues.jboss.org/browse/ISPN-1186 Project: Infinispan Issue Type: Task Affects Versions: 4.2.1.FINAL Reporter: Martin Gencur Assignee: Mircea Markus Priority: Optional Fix For: 5.0.0.CR6, 5.0.0.FINAL The documentation for Infinispan should mention different approaches for accessing remote cache (HotRod) and local (default) cache statistics. For example, there is not "evictions" statistics for remote cache. Maybe it would be enough to just mention different classes that hold these statistics (Stats and RemoteStatistics) and the way of getting them. It should be mentioned most likely somewhere under http://community.jboss.org/wiki/infinispan -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
13
0 / 0

[JBoss JIRA] (ISPN-2174) CommandAwareRpcDispatcher swallows thread interruptions

by Michal Linhard (JIRA)

Michal Linhard created ISPN-2174: ------------------------------------ Summary: CommandAwareRpcDispatcher swallows thread interruptions Key: ISPN-2174 URL: https://issues.jboss.org/browse/ISPN-2174 Project: Infinispan Issue Type: Bug Components: RPC Affects Versions: 5.1.5.FINAL Reporter: Michal Linhard Assignee: Manik Surtani When interruption happens in FutureCollator.getResponseList() method see https://github.com/infinispan/infinispan/blob/5.1.x/core/src/main/java/or... it is ignored and later wrongly dealt with as TimeoutException (The original exception is not even set as cause anywhere) This disables possibility of interrupting some cache operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
10
0 / 0

[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2173: ----------------------------------- Summary: NPE when using XA enlistment without recovery Key: ISPN-2173 URL: https://issues.jboss.org/browse/ISPN-2173 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.1.5.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.FINAL When using xa enlistment (transaction/useSynchronization=false, default), and recovery is disabled (transaction/recovery/enabled=false, default) the transaction manager might invoke recovery related methods such as XAResource.forget() in certain situations. E.g. the JBossTM invokes "forget", if during, XAResource.commit(xid, true) (second param means 1PC=true) an exception is thrown. (I expect an XAResource.rollback to be invoked in between the failed commit and forget). Here is a stack trace: {quote} 2012-07-25 14:13:42,821 WARN (testng-CheckRemoteLockAcquiredOnlyOnceDistTest:) [org.infinispan.transaction.xa.TransactionXaAdapter] Exception removing recovery information:java.lang.NullPointerException at org.infinispan.transaction.xa.TransactionXaAdapter.forget(TransactionXaAdapter.java:159) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.forget(XAResourceRecord.java:759) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:691) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2285) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1468) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenOperation(CheckRemoteLockAcquiredOnlyOnceTest.java:157) at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenPutAll(CheckRemoteLockAcquiredOnlyOnceTest.java:100) 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:601) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) at org.testng.internal.Invoker.invokeMethod(Invoker.java:673) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) {quote} As we do allow xa enlistment *without* recovery enabled this NPE shouldn't be shown to the user. Instead an warning should be logged stating that XA enlistment is configured without recovery, but recovery is used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
3
0 / 0

[JBoss JIRA] (ISPN-1841) Write skew checks are performed on all entries in a transaction context

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1841: ----------------------------------- Summary: Write skew checks are performed on all entries in a transaction context Key: ISPN-1841 URL: https://issues.jboss.org/browse/ISPN-1841 Project: Infinispan Issue Type: Bug Components: Test Suite Reporter: Manik Surtani Assignee: Mircea Markus Fix For: 5.0.2.FINAL, 5.2.0.ALPHA1 They should only be performed on entries that are read first and then updated. The current implementation doesn't cause any problems, however it is unnecessary processing and certain transactions may unnecessarily abort if, for example, an entry is read, and not written to, but the entry changes before the transaction commits. >From Pedro Ruivo's email to infinispan-dev, where this was reported: {quote} I've noticed that in the last version (5.1.x) the write skew check is performed on all keys written. However, from your documentation [1] I understood that the write skew was meant to be performed only on the written keys that were previously read. Is this change intentional? Cheers, Pedro Ruivo [1] https://docs.jboss.org/author/display/ISPN51/Data+Versioning "Write skew checks are performed at prepare-time to ensure a concurrent transaction hasn't modified an entry while it was read and potentially updated based on the value read." {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
8
0 / 0

[JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads

by Dmitry Udalov (JIRA)

Dmitry Udalov created ISPN-2013: ----------------------------------- Summary: Using explicit "unlock" causes TimeoutException for other Threads Key: ISPN-2013 URL: https://issues.jboss.org/browse/ISPN-2013 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.1.2.FINAL Environment: Windows 7 64-bit Reporter: Dmitry Udalov Assignee: Manik Surtani In a test I have several tasks that run on a single cache node configured as transactional pessimistic replicated cache. If I explicitly call "unlock" then I consistently see TimeoutException reported by some tasks. Without explicit "unlock" the test works fine. Does it mean that I should never call "unlock" and rely on transaction.commit/rollback ? It's seen with infinispan-5.1.2.FINAL Here's what in a nutshell each task does: final lockKey = ... executor.submit(new Callable<Boolean>() { public Boolean call() throws Exception TransactionManager tx = cache.getAdvancedCache().getTransactionManager(); tx.begin() try { if ( lockManager.lock(lockKey) ) { // ... // removing next line makes test happy. Otherwise some tasks report TimeoutException (pls. see the stack traces) cache.getLockManager().unlock(lockKey); } } catch(Throwable t) { tx.setRollbackOnly(); } finally { if (ut.getStatus() == Status.STATUS_ACTIVE) ut.commit(); else ut.rollback(); } By the time I received that exception all other tasks were completed and they released the lock on the key in question. I also see that LockManagerImpl.lock recognized that the lock was not owned by any thread - see "Lock held by [null]", which seems to be right. But yet the lock failed to be acquired. Is it a matter to trying it one more time? org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [foo] for requestor [GlobalTransaction:<Sound-15075>:8:local]! Lock held by [null] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:206) at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:180) at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:170) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:228) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:144) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207) at org.infinispan.interceptors.StateTransferLockInterceptor.visitLockControlCommand(StateTransferLockInterceptor.java:138) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130) at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:94) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) at org.infinispan.CacheImpl.lock(CacheImpl.java:484) at org.infinispan.CacheImpl.lock(CacheImpl.java:468) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2012