May 2012 - infinispan-issues - Jboss List Archives

[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

11 years, 6 months

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

11 years, 6 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, 6 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, 6 months

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

11 years, 6 months

4
13
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, 6 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, 6 months

6
8
0 / 0

[JBoss JIRA] Created: (ISPN-767) Make deadlock detection run over multiple caches

by Mircea Markus (JIRA)

Make deadlock detection run over multiple caches ------------------------------------------------ Key: ISPN-767 URL: https://jira.jboss.org/browse/ISPN-767 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.2.0.Final right now deadlock detection runs on a per cache basis. Eg. following deadlock won't be detected: - N1,N2 two nodes, A and B are cache running on each of them. tx1 running on N1: N1.A.put(k1); N1.B.put(k2) tx2 running in N2: N2.B.put(k2); N2.A.put(k1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1419) Clean up ConfigurationOverrides to match what 5.1 supports

by Marius Bogoevici (JIRA)

Clean up ConfigurationOverrides to match what 5.1 supports ---------------------------------------------------------- Key: ISPN-1419 URL: https://issues.jboss.org/browse/ISPN-1419 Project: Infinispan Issue Type: Bug Components: Spring integration Affects Versions: 5.1.0.ALPHA2 Reporter: Marius Bogoevici Assignee: Marius Bogoevici Fix For: 5.1.0.BETA1 Currently, ConfigurationOverrides is accessing Configuration directly through a series of deprecated methods. Make this fully compatible with Infinispan 5.1 and use FluentConfiguration instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

4
13
0 / 0

[JBoss JIRA] Created: (ISPN-1068) Add usage support similar to the one included in Spring Data

by Marius Bogoevici (JIRA)

Add usage support similar to the one included in Spring Data ------------------------------------------------------------ Key: ISPN-1068 URL: https://issues.jboss.org/browse/ISPN-1068 Project: Infinispan Issue Type: Feature Request Reporter: Marius Bogoevici Assignee: Manik Surtani ... i.e. InfinispanTemplate/InfinispanCallback -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
20
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2012