September 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-949) Have something like Hibernate's ResultTransformer for Query results

by Sanne Grinovero (JIRA)

Have something like Hibernate's ResultTransformer for Query results ------------------------------------------------------------------- Key: ISPN-949 URL: https://issues.jboss.org/browse/ISPN-949 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Minor Fix For: 6.0.0.Final Be able to transform an array of projected fields into a nice object. So return a List<CustomBean>, instead of a List<Object[]> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-893) Addtional attribute on @CacheEntryCreated to get on pre notifications only

by Sudheer Krishna (JIRA)

Addtional attribute on @CacheEntryCreated to get on pre notifications only ----------------------------------------------------------------------------- Key: ISPN-893 URL: https://issues.jboss.org/browse/ISPN-893 Project: Infinispan Issue Type: Enhancement Components: Listeners Affects Versions: 4.2.0.Final Environment: ALL Reporter: Sudheer Krishna Assignee: Manik Surtani Priority: Minor I may have usescases where i need notifications only when isPre = true. I was expecting a parameter to be taken by @CacheEntryCreated. But this doesnt seem to take any parametres. Aslo i would like similar values on @CacheEntryremoved also. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

4
17
0 / 0

[JBoss JIRA] Created: (ISPN-999) Support eventual consistency

by Manik Surtani (JIRA)

Support eventual consistency ---------------------------- Key: ISPN-999 URL: https://issues.jboss.org/browse/ISPN-999 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Locking and Concurrency Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final Essentially, it is about supporting eventual consistency in Infinispan. Currently Infinispan is strongly consistent when using synchronous distribution mode. Each data owner receives updates synchronously so anyone anywhere on the cluster doing a GET will see the correct value. The only exception is during a rehash (when a new node joins or leaves), that consistency is eventual since the GET may reach a new joiner who may not have applied state it receives from its neighbours yet. However this is hidden from users since the GET is sent to> 1 data owner and if an UnsureResponse is received (determined by the fact that a new joiner responds and the new joiner wouldn't have finished applying state), the caller thread waits for more definite responses. However, there is a use case for being eventually consistent as well: the main benefits being speed and partition tolerance. E.g., if we use distribution in asynchronous mode, the writes become *much* faster. However, anyone anywhere doing a GET will have to perform the GET on all data owners, and compare the versions of the data received to determine which is the latest. And if there is a conflict, to pass back all values to the user. So in terms of design, what I have in mind is: * All cache entries are versioned using vector clocks. One vector clock per node. * When a node performs a GET, the GET is sent to all data owners (concurrently), and the value + version is retrieved from each. * If the versions are all the same (or they can be "fast forwarded"), the value is returned * Otherwise, all potential values and their versions are returned * A resolve() API should be provided where application code may provide a "hint" as to which version should be "correct" - which will cause an update. * In terms of implementation, this will touch the DistributionInterceptor, InternalCacheEntry and relevant factories, some config code (since this should be consistency model should be configurable), and a new public interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-1394) Investigate possibility of doing manual rehashing

by Galder Zamarreño (JIRA)

Investigate possibility of doing manual rehashing ------------------------------------------------- Key: ISPN-1394 URL: https://issues.jboss.org/browse/ISPN-1394 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.2.0.FINAL Investigate the possibility of being able to do manual rehashing: - Approach used Dynamo (and Cassandra) - If you're adding 100 nodes, using manual rehashing could reduce traffic and make it more predictable - Could be called via JMX - But removing 10 nodes could be problematic. Unless number of owners is 11 or higher, which will guarantee that at least a copy of data is around -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
4
0 / 0

[JBoss JIRA] Created: (ISPN-1147) Programmatically creating cache should be automatically reflected throughout the cluster

by Randall Hauch (JIRA)

Programmatically creating cache should be automatically reflected throughout the cluster ---------------------------------------------------------------------------------------- Key: ISPN-1147 URL: https://issues.jboss.org/browse/ISPN-1147 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, State transfer Affects Versions: 4.2.1.FINAL Reporter: Randall Hauch Assignee: Manik Surtani Consider a symmetric cluster of two nodes (N1 and N2) each with a single cache (C1). Currently, a new cache (C2) must be programmatically created _on all all nodes in the cluster_ (if REPL, or all appropriate nodes if DIST) _before_ that new cache can even be _used_. Ideally, when a new cache (C2) is created on one node (N1), Infinispan should automatically propagate that creation to the appropriate nodes in the cluster so that the new cache can be used immediately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

7
9
0 / 0

[JBoss JIRA] Created: (ISPN-1418) FileCacheStore throws an IllegalMonitorStateException in FileCacheVamTest

by Dan Berindei (JIRA)

FileCacheStore throws an IllegalMonitorStateException in FileCacheVamTest ------------------------------------------------------------------------- Key: ISPN-1418 URL: https://issues.jboss.org/browse/ISPN-1418 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.ALPHA2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 5.1.0.BETA1 If there are no expired elements the bucket will not be modified and the lock doesn't need to be acquired. We were still releasing the lock though, leading to IllegalMonitorStateExceptions in FileCacheStoreVamTest: 2011-09-25 11:54:46,000 ERROR (testng-FileCacheStoreVamTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Method testLoadAndStoreWithLifespan(org.infinispan.loaders.file.FileCacheStoreVamTest) threw an exception java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:398) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:778) at org.infinispan.util.concurrent.locks.StripedLock.releaseLock(StripedLock.java:135) at org.infinispan.loaders.LockSupportCacheStore.unlock(LockSupportCacheStore.java:87) at org.infinispan.loaders.file.FileCacheStore.purgeInternal(FileCacheStore.java:244) at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:106) at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:48) at org.infinispan.loaders.AbstractCacheStore.purgeExpired(AbstractCacheStore.java:103) at org.infinispan.loaders.BaseCacheStoreTest.purgeExpired(BaseCacheStoreTest.java:198) at org.infinispan.loaders.BaseCacheStoreTest.testLoadAndStoreWithLifespan(BaseCacheStoreTest.java:151) 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:616) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeMethod(Invoker.java:546) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:909) at org.testng.TestRunner.privateRun(TestRunner.java:618) at org.testng.TestRunner.run(TestRunner.java:499) at org.testng.SuiteRunner.runTest(SuiteRunner.java:332) at org.testng.SuiteRunner.access$000(SuiteRunner.java:33) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:358) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:142) 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:679) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

6
9
0 / 0

[JBoss JIRA] Created: (ISPN-1417) Inefficient and unnecessary clearing of looked up entries when a context is reset

by Manik Surtani (JIRA)

Inefficient and unnecessary clearing of looked up entries when a context is reset --------------------------------------------------------------------------------- Key: ISPN-1417 URL: https://issues.jboss.org/browse/ISPN-1417 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.1.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.FINAL When a context is reset, some implementations call clear() on the looked up entries map. This can be inefficient in microbenchmarks if a large number of entries have been looked up. Contexts should simply nullify looked up entries and let the collection be gc'd. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1378) Log Infinispan version only once

by Michal Linhard (JIRA)

Log Infinispan version only once -------------------------------- Key: ISPN-1378 URL: https://issues.jboss.org/browse/ISPN-1378 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.0.0.FINAL Reporter: Michal Linhard Assignee: Manik Surtani The log message with version {code} 16:13:15,245 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:15,750 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-2) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:16,302 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:16,359 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:16,705 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT {code} is logged in AbstractComponentRegistry and therefore it's logged for each configured cache. Wouldn't one such message suffice for one CacheManager instance ? e.g. log it at the end of GlobalComponentRegistry.start() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
4
0 / 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2011