October 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2435) Cache#replace(key, old, new) method doesn't check old value on non-local invocations

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2435: ------------------------------------- Summary: Cache#replace(key, old, new) method doesn't check old value on non-local invocations Key: ISPN-2435 URL: https://issues.jboss.org/browse/ISPN-2435 Project: Infinispan Issue Type: Bug Components: Core API, Distributed Cache Affects Versions: 5.1.8.Final, 5.2.0.Beta2 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 5.2.0.CR1 -- 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, 9 months

2
8
0 / 0

[JBoss JIRA] (ISPN-2384) Entry lost after Eviction/Passivation

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2384: ---------------------------------- Summary: Entry lost after Eviction/Passivation Key: ISPN-2384 URL: https://issues.jboss.org/browse/ISPN-2384 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.2.0.Beta1 Reporter: Thomas Fromm Assignee: Mircea Markus Attachments: eviction.log Cache is LOCAL, eviction + passivation enabled. After put the entry gets passivated, shortly after an other thread tries to get() the entry, but get null. Attached a log file. The key is "50b2c9e7-0a38-0043-01fc-76cdf49fa2ce". Tried JDBC and File store with same results, also sync/async store tested. It happens under some load. -- 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, 9 months

4
15
0 / 0

[JBoss JIRA] (ISPN-2362) Potential inconsistency during NBST

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2362: ----------------------------------- Summary: Potential inconsistency during NBST Key: ISPN-2362 URL: https://issues.jboss.org/browse/ISPN-2362 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 The NBST functionality leaves place to inconsistencies during removals: 1. the joiner first requests transaction data 2. after all transaction data is integrated (i.e. tx is prepared on the state receiver node) it requests the rest of the data (from data container) 3. in order not to override the data from transactions which is more recent (transactions at step 1 might have been committed during step 2), the data at 2 inserts data in the cache with putIfAbsent. Whilst this prevents from overriding newer values as written by transactions, it doesn't guard against the situation in which the tx removed data. So it is possible for deleted data a to resurrect. A possible solution to this inconsistency issue is by using tombstones for the duration of the state transfer. -- 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, 9 months

2
11
0 / 0

[JBoss JIRA] (ISPN-2192) Allow using Distributed Execution against any cache (not just clustered caches)

by Randall Hauch (JIRA)

Randall Hauch created ISPN-2192: ----------------------------------- Summary: Allow using Distributed Execution against any cache (not just clustered caches) Key: ISPN-2192 URL: https://issues.jboss.org/browse/ISPN-2192 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.2.FINAL Reporter: Randall Hauch Assignee: Manik Surtani Priority: Critical It is often desirable to process all entries in a cache, and there is no reliable and consistent way to do that for any cache. If a cache is clustered, then map-reduce can be used (although IIUC it currently doesn't guarantee to process non-materialized entries for caches that have a cache store) and distributed execution can be used (IIUC this will be called for all keys owned by the cluster node). However, neither of these work on local caches. If a cache is local and there is no cache store, then apparently {{keySet()}} does work and allows a client to iterate over the keys in the local cache. However, if the local cache is configured to have a cache store, then the {{keySet()}} method will return only the keys for the materialized entries and does not return all of the keys in the cache. Of course, if a local cache does have a cache store, then its possible to obtain the keys using {{CacheLoader.loadAllKeys(...)}} (obviously this is probably not something a client should do). In short, it should be possible to use Distributed Execution against any cache, regardless of its configuration. (Ideally, it would be possible for Map-Reduce to also be used against any cache.) -- 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, 9 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2106) StateTransferFunctionalTest.testSTWithThirdWritingNonTxCache failing randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2106: -------------------------------------- Summary: StateTransferFunctionalTest.testSTWithThirdWritingNonTxCache failing randomly Key: ISPN-2106 URL: https://issues.jboss.org/browse/ISPN-2106 Project: Infinispan Issue Type: Bug Components: State transfer, Test Suite Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.2.0.ALPHA1 See: https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/org.in... and https://infinispan.ci.cloudbees.com/job/Infinispan-5.1.x-JDK6-tcp/org.inf... -- 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, 9 months

5
14
0 / 0

[JBoss JIRA] (ISPN-2323) RemoteCacheStore should optionally put/get raw values (instead of InternalCacheEntries)

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2323: ------------------------------------- Summary: RemoteCacheStore should optionally put/get raw values (instead of InternalCacheEntries) Key: ISPN-2323 URL: https://issues.jboss.org/browse/ISPN-2323 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.Final Accessing a remote HotRod cache via a RemoteCacheManager and a RemoteCacheStore is not possible since the former stores plain values whereas the latter stores InternalCacheEntries. We should enhance the RemoteCacheStore to be able to "unwrap/wrap" cache entries -- 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, 9 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-1293) Enable default lifespan/maxIdle values to be used by the Hot Rod server

by Galder Zamarreño (JIRA)

Enable default lifespan/maxIdle values to be used by the Hot Rod server ----------------------------------------------------------------------- Key: ISPN-1293 URL: https://issues.jboss.org/browse/ISPN-1293 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.FINAL Hot Rod clients should be able to tell the server that no lifespan/maxIdle value was given, and so that the server should use the default lifespan+maxIdle values set in configuration. This is not currently possible in v1 of the protocol and so requires a change of protocol. This is the result of the investigation for ISPN-1285, and so when this is resolved: 1. Make sure you revert the javadoc added to ISPN-1285 to document the limitation 2. Enable and expand client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ExpiryTest.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

4
9
0 / 0

[JBoss JIRA] (ISPN-2378) IllegalMonitorStateException when using LockSupportCacheStore.loadAllKeys

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2378: ---------------------------------- Summary: IllegalMonitorStateException when using LockSupportCacheStore.loadAllKeys Key: ISPN-2378 URL: https://issues.jboss.org/browse/ISPN-2378 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.2.0.Beta1 Reporter: Thomas Fromm Assignee: Mircea Markus Priority: Critical When accessing cache store from different threads: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447) at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883) at org.infinispan.util.concurrent.locks.StripedLock.releaseGlobalLock(StripedLock.java:243) at org.infinispan.loaders.LockSupportCacheStore.releaseGlobalLock(LockSupportCacheStore.java:134) at org.infinispan.loaders.LockSupportCacheStore.loadAllKeys(LockSupportCacheStore.java:177) ... -- 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, 9 months

3
15
0 / 0

[JBoss JIRA] (ISPN-2360) LIRS is not mentioned in the documentation

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2360: ------------------------------------- Summary: LIRS is not mentioned in the documentation Key: ISPN-2360 URL: https://issues.jboss.org/browse/ISPN-2360 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 5.2.0.Beta1 LIRS is barely mentioned in some descriptions as being the default eviction strategy, but it's not listed nor described in any form: https://docs.jboss.org/author/display/ISPN/Eviction -- 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, 9 months

4
10
0 / 0

[JBoss JIRA] (ISPN-1884) expose hibernate search search factory statistics jmx

by Mathieu Lachance (JIRA)

Mathieu Lachance created ISPN-1884: -------------------------------------- Summary: expose hibernate search search factory statistics jmx Key: ISPN-1884 URL: https://issues.jboss.org/browse/ISPN-1884 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Affects Versions: 5.1.1.FINAL Reporter: Mathieu Lachance Assignee: Manik Surtani it is possible to add jmx hook to obtain Hibernate Search SearchFactory Statistics by using this property : <indexing enabled="true" indexLocalOnly="true"> <properties> <property name="hibernate.search.jmx_enabled" value="true" /> </properties> </indexing> tough this property does not allow multiple registration (one registration per cache). it would be nice to wrap the Statistics object from HibernateSearch into the actual cache object mbean. i guess the implementation could look like this : // get search factory statistics org.hibernate.search.stat.Statistics statistics = Search.getSearchManager(org.infinispan.Cache).getSearchFactory().getStatistics(); // wrap search factory statistics SearchFactoryStatisticMBean mbean = new SearchFactoryStatisticMBeanImpl(statistics); // expose mbean ManagementFactory.getPlatformMBeanServer().registerMBean(new ObjectName("..."), mbean); -- 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, 9 months

6
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012