[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
[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
[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
[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
[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
[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
[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