June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3202) Infinispan cachestores remove entries early when maxIdle used

by Ralph Jennings (JIRA)

Ralph Jennings created ISPN-3202: ------------------------------------ Summary: Infinispan cachestores remove entries early when maxIdle used Key: ISPN-3202 URL: https://issues.jboss.org/browse/ISPN-3202 Project: Infinispan Issue Type: Bug Affects Versions: 5.2.6.Final Environment: Linux: debian wheezy uname -a: Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux JBoss: 7.1.2.Final Embedded cache using infinispan 5.2.6.Final jars included in WAR's WEB-INF/lib directory. Reporter: Ralph Jennings Assignee: Mircea Markus When adding an entry to the cache (embedded), specifying maxIdle... The entry goes into the store, but the store removes the entry when maxIdle time elapses from creation (rather than from last access). The cache correctly keeps the entry in memory (unless evicted). This leaves the cache and store out of sync. I saw this same behavior with both stringKeyedJdbcStore and fileStore. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3161) ClusterFileCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap fails intermittently

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3161?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3161: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ClusterFileCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap fails intermittently > ------------------------------------------------------------------------------------------ > > Key: ISPN-3161 > URL: https://issues.jboss.org/browse/ISPN-3161 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Test Suite > Affects Versions: 5.3.0.CR1 > Reporter: William Burns > Assignee: Mircea Markus > Attachments: infinispan.zip > > > This test fails intermittently with a TimeoutException. > The easiest way to reproduce is just to add an @Test annotation setting the invocationCount to 1000 or more. > I have attached a trace when the error occurs. > {code} > 2013-05-30 17:27:41,660 ERROR (main) [org.infinispan.interceptors.InvocationContextInterceptor] ISPN000136: Execution error > org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [0 milliseconds] on key [testRestoreTransactionalAtomicMap] for requestor [Thread[main,5,main]]! Lock held by [GlobalTransaction:<NodeA-52943>:700:remote] > at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:214) > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:197) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitEvictCommand(AbstractTxLockingInterceptor.java:86) > at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134) > at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79) > at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134) > at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79) > at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134) > at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79) > at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) > at org.infinispan.statetransfer.StateTransferInterceptor.visitEvictCommand(StateTransferInterceptor.java:179) > at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92) > at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79) > at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343) > at org.infinispan.CacheImpl.evict(CacheImpl.java:538) > at org.infinispan.CacheImpl.evict(CacheImpl.java:531) > at org.infinispan.loaders.file.ClusterFileCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap(ClusterFileCacheStoreFunctionalTest.java:101) > .... > {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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3201) Allow listeners to be invoked only by a primary data owner

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3201?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-3201 at 6/6/13 1:04 PM: ------------------------------------------------------------- Here is an interesting discussion on this topic: http://markmail.org/message/um5sqnhhqxwa6tix was (Author: mircea.markus): Here is an interesting discussion on this topic: http://infinispan.markmail.org/search/?q=singleton+%40Listener#query:sing... > Allow listeners to be invoked only by a primary data owner > ---------------------------------------------------------- > > Key: ISPN-3201 > URL: https://issues.jboss.org/browse/ISPN-3201 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, Listeners > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > Could be a parameter on the annotation, such as {{primaryOwnerOnly}} to prevent all replicas from firing updates. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3201) Allow listeners to be invoked only by a primary data owner

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3201?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3201: ------------------------------------- Here is an interesting discussion on this topic: http://infinispan.markmail.org/search/?q=singleton+%40Listener#query:sing... > Allow listeners to be invoked only by a primary data owner > ---------------------------------------------------------- > > Key: ISPN-3201 > URL: https://issues.jboss.org/browse/ISPN-3201 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, Listeners > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > Could be a parameter on the annotation, such as {{primaryOwnerOnly}} to prevent all replicas from firing updates. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3197) Message ordering of Get and Invalidation can cause L1 to be inconsistent

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3197?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3197: -------------------------------- Affects Version/s: 5.2.6.Final > Message ordering of Get and Invalidation can cause L1 to be inconsistent > ------------------------------------------------------------------------ > > Key: ISPN-3197 > URL: https://issues.jboss.org/browse/ISPN-3197 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > > This is based off of discussion here: https://issues.jboss.org/browse/ISPN-2990?focusedCommentId=12779491&page=... > This can occur with a synchronous cache. > 1. A reads k1. This is an OOB call. > 2. B processes the read message and sends back the response > 3. C updates k1, at this stage B sends the invalidation message to A (OOB call) > 4. A processes(ignores) the invalidation message > 5. A puts the stale value sent at 2 in L1 > The OOB portions don't actually matter that they are OOB as even if B's messages were ordered it sill could process the get and update in a different order since they originate from different nodes. > The initial thought is to solve this with some type of tombstone to sygnal the removal of the L1 cache, but this also still doesn't catch the problem if A did not have key k1 in it's L1 cache to receive an invalidation message. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3197) Message ordering of Get and Invalidation can cause L1 to be inconsistent

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3197?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3197: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > Message ordering of Get and Invalidation can cause L1 to be inconsistent > ------------------------------------------------------------------------ > > Key: ISPN-3197 > URL: https://issues.jboss.org/browse/ISPN-3197 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > > This is based off of discussion here: https://issues.jboss.org/browse/ISPN-2990?focusedCommentId=12779491&page=... > This can occur with a synchronous cache. > 1. A reads k1. This is an OOB call. > 2. B processes the read message and sends back the response > 3. C updates k1, at this stage B sends the invalidation message to A (OOB call) > 4. A processes(ignores) the invalidation message > 5. A puts the stale value sent at 2 in L1 > The OOB portions don't actually matter that they are OOB as even if B's messages were ordered it sill could process the get and update in a different order since they originate from different nodes. > The initial thought is to solve this with some type of tombstone to sygnal the removal of the L1 cache, but this also still doesn't catch the problem if A did not have key k1 in it's L1 cache to receive an invalidation message. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3197) Message ordering of Get and Invalidation can cause L1 to be inconsistent

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3197?page=com.atlassian.jira.plugin.... ] Work on ISPN-3197 started by William Burns. > Message ordering of Get and Invalidation can cause L1 to be inconsistent > ------------------------------------------------------------------------ > > Key: ISPN-3197 > URL: https://issues.jboss.org/browse/ISPN-3197 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > > This is based off of discussion here: https://issues.jboss.org/browse/ISPN-2990?focusedCommentId=12779491&page=... > This can occur with a synchronous cache. > 1. A reads k1. This is an OOB call. > 2. B processes the read message and sends back the response > 3. C updates k1, at this stage B sends the invalidation message to A (OOB call) > 4. A processes(ignores) the invalidation message > 5. A puts the stale value sent at 2 in L1 > The OOB portions don't actually matter that they are OOB as even if B's messages were ordered it sill could process the get and update in a different order since they originate from different nodes. > The initial thought is to solve this with some type of tombstone to sygnal the removal of the L1 cache, but this also still doesn't catch the problem if A did not have key k1 in it's L1 cache to receive an invalidation message. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3201) Allow listeners to be invoked only by a primary data owner

by Manik Surtani (JIRA)

Manik Surtani created ISPN-3201: ----------------------------------- Summary: Allow listeners to be invoked only by a primary data owner Key: ISPN-3201 URL: https://issues.jboss.org/browse/ISPN-3201 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Listeners Affects Versions: 5.3.0.Final Reporter: Manik Surtani Assignee: Mircea Markus Fix For: 6.0.0.Alpha1, 6.0.0.Final Could be a parameter on the annotation, such as {{primaryOwnerOnly}} to prevent all replicas from firing updates. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3200) Allow KeyFilters to be applied to listeners

by Manik Surtani (JIRA)

Manik Surtani created ISPN-3200: ----------------------------------- Summary: Allow KeyFilters to be applied to listeners Key: ISPN-3200 URL: https://issues.jboss.org/browse/ISPN-3200 Project: Infinispan Issue Type: Feature Request Components: Listeners Affects Versions: 5.3.0.Final Reporter: Manik Surtani Assignee: Mircea Markus Fix For: 6.0.0.Alpha1, 6.0.0.Final When registering a listener, users should be able to provide a {{KeyFilter}}, a simple interface that determines whether a listener is invoked or not based on whether the affected key(s) matches the filter. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3199) API to manipulate multiple versions of an entry

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-3199?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-3199: -------------------------------- Estimated Difficulty: Medium > API to manipulate multiple versions of an entry > ----------------------------------------------- > > Key: ISPN-3199 > URL: https://issues.jboss.org/browse/ISPN-3199 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 7.0.0.Final > > > In addition to the existing API, the following will be needed to allow user applications to directly control versioning. E.g., > {code} > put(K key, EntryVersion version); > get(K key, EntryVersion version); > getLatest(K key, EntryVersion upperBound); > evict(K key, EntryVersion upTo); > {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

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013