October 2012 - infinispan-issues - Jboss List Archives

[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

11 years, 8 months

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

11 years, 8 months

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

11 years, 8 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2406) StaleTransactionCleanupService should not try to attempt cleanup if the local cache is stopping

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2406: ----------------------------------- Summary: StaleTransactionCleanupService should not try to attempt cleanup if the local cache is stopping Key: ISPN-2406 URL: https://issues.jboss.org/browse/ISPN-2406 Project: Infinispan Issue Type: Bug Components: State transfer, Transactions Affects Versions: 5.2.0.ALPHA1 Reporter: Adrian Nistor Assignee: Mircea Markus Priority: Minor Fix For: 5.2.0.Final While a cache is stopping there is a small window of time in which the StaleTransactionCleanupService still runs until the component registry manages to stop the TransactionTable and StaleTransactionCleanupService. The service might try to rollback transactions but the cache can no longer accept the rollback command because of its current status. This leads to exceptions being logged. This has no negative impact but is not ideal. 2012-10-15 19:23:19,740 TRACE [TransactionTable] (LockBreakingService,___defaultcache,NodeC-54695) Killing remote transaction originating on leaver GlobalTransaction:<NodeA-995>:1206:local 2012-10-15 19:23:19,740 TRACE [AbstractTransactionBoundaryCommand] (LockBreakingService,___defaultcache,NodeC-54695) About to execute tx command RollbackCommand {gtx=GlobalTransaction:<NodeA-995>:1206:remote, cacheName='___defaultcache', topologyId=-1} 2012-10-15 19:23:19,743 WARN [TransactionTable] (LockBreakingService,___defaultcache,NodeC-54695) ISPN000102: Unable to roll back global transaction GlobalTransaction:<NodeA-995>:1206:remote java.lang.IllegalStateException: Default cache is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container. at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:111) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:93) at org.infinispan.commands.AbstractVisitor.visitRollbackCommand(AbstractVisitor.java:132) at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:55) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:347) at org.infinispan.commands.tx.AbstractTransactionBoundaryCommand.perform(AbstractTransactionBoundaryCommand.java:118) at org.infinispan.transaction.TransactionTable.updateStateOnNodesLeaving(TransactionTable.java:243) at org.infinispan.transaction.StaleTransactionCleanupService$1.run(StaleTransactionCleanupService.java:150) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- 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

11 years, 8 months

2
3
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

11 years, 8 months

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

11 years, 8 months

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

11 years, 8 months

2
3
0 / 0

[JBoss JIRA] (ISPN-2391) Throw consistent IllegalStateException(s) for ReplicableCommand#setParameters(int commandId, Object[] parameters)

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-2391: ----------------------------------------- Summary: Throw consistent IllegalStateException(s) for ReplicableCommand#setParameters(int commandId, Object[] parameters) Key: ISPN-2391 URL: https://issues.jboss.org/browse/ISPN-2391 Project: Infinispan Issue Type: Task Components: RPC Affects Versions: 5.2.0.Beta1 Reporter: Vladimir Blagojevic Assignee: Mircea Markus Fix For: 5.2.0.Final During review of https://github.com/infinispan/infinispan/pull/1369 Manik observed inconsistency in wording of IllegalStateException thrown from ReplicableCommand#setParameters(int commandId, Object[] parameters). However, upon further review it was noted that all implementations of ReplicableCommand#setParameters(int commandId, Object[] parameters) are inconsistent potentially confusing sys admins and support engineers. We should create a single consistent messages for all implementations of ReplicableCommand#setParameters(int commandId, Object[] parameters). -- 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

11 years, 8 months

2
1
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

11 years, 8 months

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

11 years, 8 months

6
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012