April 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1347) LIRS eviction not evicting correctly

by Jozef Vilkolak (JIRA)

LIRS eviction not evicting correctly ------------------------------------ Key: ISPN-1347 URL: https://issues.jboss.org/browse/ISPN-1347 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.0.0.FINAL Reporter: Jozef Vilkolak Assignee: Manik Surtani It seems LIRS eviction at this moment only evicts the first entry in the HIR queue and nothing else. I have written a test based on [this presentation|https://docs.google.com/viewer?a=v&q=cache:jcEF5qSkCo4J:www....] located in the eviction-strategy module of [edg-functional-tests|https://svn.devel.redhat.com/repos/jboss-qa/edg/edg-...] that is at the moment failing. Upon closer examination I have found a couple of things I think may be the cause: * in infinispan.util.concurrent.BoundedConcurrentHashMap ** in execute() of the LIRS eviction if you have more items in the accessQueue and while processing you choose an item to be evicted it is added to the evicted Set. But if it is still in the accessQueue(and the operation was put) it gets proccesed but in the end still ends up evicted because it was not removed from the evicted set. ** in onEntryMiss of the LIRS eviction the very first if shouldn't first increment currentLIRSize because otherwise LIRSize is never full and therefore the LIRS algorithm never truly happens because execute() is never called that's why it only evicts from the HIR queue. It also causes the cache to be able to hold only maxEntries-1 entries. Also if (queue.size() < hirSizeLimit) condition is true the item should also be added to the stack in order to track its recency. And lastly I don't think onEntryMiss should be evicting elements because that way we can't track their recency. They will get eventually evicted by pruning. ** the function onEntryRemove should not in my opinion remove entries from the stack because otherwise there is no way to track recency of HIR-nonresident blocks. They will eventually get removed from the stack by pruning. It also seems this function gets called when clearing the cache instead of clear. * in Segment class ** the remove operation makes entries behave as if they were just added as is already documented there with a TODO ** the get operation calls onEntryHit which can cause problems if get is used while servicing a put operation because it gets called twice If some of these things were design choices let me know so I will modify the test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

6
11
0 / 0

[JBoss JIRA] Created: (ISPN-1320) indexing properties defined for <namedCache/> in xml are ignored therefore indexes are always persistent

by Jan Slezak (JIRA)

indexing properties defined for <namedCache/> in xml are ignored therefore indexes are always persistent -------------------------------------------------------------------------------------------------------- Key: ISPN-1320 URL: https://issues.jboss.org/browse/ISPN-1320 Project: Infinispan Issue Type: Bug Reporter: Jan Slezak Assignee: Manik Surtani indexing properties defined for <namedCache/> in xml are ignored therefore indexes are always persistent; see reproduction steps for xml / UT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

6
17
0 / 0

[JBoss JIRA] (ISPN-1800) indexes are added instead of updated after cache restart

by Jan Slezak (JIRA)

Jan Slezak created ISPN-1800: -------------------------------- Summary: indexes are added instead of updated after cache restart Key: ISPN-1800 URL: https://issues.jboss.org/browse/ISPN-1800 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 5.1.0.FINAL, 5.0.1.FINAL Environment: Fedora 15 Reporter: Jan Slezak Assignee: Sanne Grinovero Problem with index addition instead of update after cache restart therefore there may arise inconsistencies data vs. indexes -- 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

3
7
0 / 0

[JBoss JIRA] (ISPN-2003) Query module broken

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2003: ------------------------------------- Summary: Query module broken Key: ISPN-2003 URL: https://issues.jboss.org/browse/ISPN-2003 Project: Infinispan Issue Type: Bug Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Blocker Fix For: 5.1.4.FINAL, 5.2.0.ALPHA1 A change in generics usage caused the Query module to break badly: 55 test errors. -- 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

2
2
0 / 0

[JBoss JIRA] (ISPN-2004) Update to Hibernate Search 4.1.0.Final

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2004: ------------------------------------- Summary: Update to Hibernate Search 4.1.0.Final Key: ISPN-2004 URL: https://issues.jboss.org/browse/ISPN-2004 Project: Infinispan Issue Type: Component Upgrade Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.4.FINAL -- 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

2
2
0 / 0

[JBoss JIRA] (ISPN-2009) Enable queueing in JGroups for non-OOB messages

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2009: ---------------------------------- Summary: Enable queueing in JGroups for non-OOB messages Key: ISPN-2009 URL: https://issues.jboss.org/browse/ISPN-2009 Project: Infinispan Issue Type: Task Components: RPC Affects Versions: 5.1.3.FINAL Reporter: Dan Berindei Assignee: Manik Surtani Fix For: 5.1.4.FINAL, 5.2.0.ALPHA1 Queueing is a problem for sync/OOB messages because it might cause deadlocks, but non-OOB messages are reordered by JGroups anyway so there's no problem with queueing there. It should be a tiny bit faster because it needs fewer threads. -- 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

2
1
0 / 0

[JBoss JIRA] (ISPN-1976) Expose cluster partition name

by Heiko Rupp (JIRA)

Heiko Rupp created ISPN-1976: -------------------------------- Summary: Expose cluster partition name Key: ISPN-1976 URL: https://issues.jboss.org/browse/ISPN-1976 Project: Infinispan Issue Type: Feature Request Reporter: Heiko Rupp Assignee: Manik Surtani [11:07:36] <pilhuhn> how can I get the cluster partition name in as7 Similar to what was in as4/5 ? Is that now on subsystem=infinispan/cache=*:aliases ? [11:32:15] <+galderz> pilhuhn, i don't think we're exposing it: http://docs.jboss.org/infinispan/5.1/apidocs/jmxComponents.html [11:32:30] <+galderz> we could expose it via the cache manager [11:33:12] <+galderz> pilhuhn, can u add a jira for that? -- 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

5
8
0 / 0

[JBoss JIRA] (ISPN-1792) Modification timestamp of cache entries

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-1792: ---------------------------------- Summary: Modification timestamp of cache entries Key: ISPN-1792 URL: https://issues.jboss.org/browse/ISPN-1792 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.1.0.FINAL Reporter: Thomas Fromm Assignee: Manik Surtani To realise things like: programmatic delete last X entries from cache, I need the modification timestamp of the cache entry. ATM I store it inside the key object (cause I cannot modify value objects) and have my own index on this. Getting the modification timestamp using the advanced cache api would be really nice. -- 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

2
7
0 / 0

[JBoss JIRA] (ISPN-2002) Resolve usage of many older deprecated methods in Lucene Directory

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2002: ------------------------------------- Summary: Resolve usage of many older deprecated methods in Lucene Directory Key: ISPN-2002 URL: https://issues.jboss.org/browse/ISPN-2002 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 5.2.0.ALPHA1 -- 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

2
2
0 / 0

[JBoss JIRA] (ISPN-2000) KeyAffinityServiceImpl not resetting interrupt state of thread

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2000: ------------------------------------- Summary: KeyAffinityServiceImpl not resetting interrupt state of thread Key: ISPN-2000 URL: https://issues.jboss.org/browse/ISPN-2000 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.4.CR1 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.4.FINAL, 5.2.0.ALPHA1 This was still hanging in tests for me, I found it was happening as the threads were ignoring the interruption request from the Executor service managing them. -- 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

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2012