[JBoss JIRA] (ISPN-3164) Replacing entry via Memcached does not increment version of original HotRod entry
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3164?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3164:
-------------------------------------
As you might expect, replacing the entry via REST results in NPE on the last HotRod client's call:
{code}
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.NullPointerException
at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:162)
at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:118)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:78)
at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:74)
at org.infinispan.client.hotrod.impl.operations.GetWithVersionOperation.executeOperation(GetWithVersionOperation.java:58)
at org.infinispan.client.hotrod.impl.operations.GetWithVersionOperation.executeOperation(GetWithVersionOperation.java:45)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:68)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getVersioned(RemoteCacheImpl.java:159)
at org.infinispan.it.compatibility.EmbeddedRestMemcachedHotRodTest.testHotRodPutMemcachedReplaceHotRodGetVersionedTest(EmbeddedRestMemcachedHotRodTest.java:204)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{code}
This is perhaps for a separate JIRA? If we don't fix it, we should at least document that this does not work. But in order to have fully compatible endpoints, it would be nice to fix this.
> Replacing entry via Memcached does not increment version of original HotRod entry
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3164
> URL: https://issues.jboss.org/browse/ISPN-3164
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> When an entry is stored via HotRod and later replaced by Memcached (or Embedded, it does not matter), the version of the entry does not change. This makes operations like replaceWithVersion of HotRod client unreliable in compatibility mode.
> {code:java}
> public void testHotRodPutMemcachedReplaceHotRodGetVersionedTest() throws Exception {
> final String key1 = "6";
> // 1. Put with Hot Rod
> RemoteCache<String, Object> remote = cacheFactory.getHotRodCache();
> assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key1, "v1"));
> VersionedValue oldValue = remote.getVersioned(key1);
> // 2. Replace with Memcached
> Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v2");
> assertTrue(f.get(60, TimeUnit.SECONDS));
> // 3. Get with HotRod
> assertEquals("v2", remote.getVersioned(key1).getValue());
> assertTrue("The entry version should have changed", oldValue.getVersion() != remote.getVersioned(key1).getVersion());
> //^^^ fails here
> }
> {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
[JBoss JIRA] (ISPN-3164) Replacing entry via Memcached does not increment version of original HotRod entry
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3164:
-----------------------------------
Summary: Replacing entry via Memcached does not increment version of original HotRod entry
Key: ISPN-3164
URL: https://issues.jboss.org/browse/ISPN-3164
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.3.0.CR1
Reporter: Martin Gencur
Assignee: Galder Zamarreño
Fix For: 5.3.0.Final
When an entry is stored via HotRod and later replaced by Memcached (or Embedded, it does not matter), the version of the entry does not change. This makes operations like replaceWithVersion of HotRod client unreliable in compatibility mode.
{code:java}
public void testHotRodPutMemcachedReplaceHotRodGetVersionedTest() throws Exception {
final String key1 = "6";
// 1. Put with Hot Rod
RemoteCache<String, Object> remote = cacheFactory.getHotRodCache();
assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key1, "v1"));
VersionedValue oldValue = remote.getVersioned(key1);
// 2. Replace with Memcached
Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v2");
assertTrue(f.get(60, TimeUnit.SECONDS));
// 3. Get with HotRod
assertEquals("v2", remote.getVersioned(key1).getValue());
assertTrue("The entry version should have changed", oldValue.getVersion() != remote.getVersioned(key1).getVersion());
//^^^ fails here
}
{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
[JBoss JIRA] (ISPN-3163) Replacing entry via HotRod which was initially stored via Memcached does not change CAS
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3163?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3163:
-------------------------------------
If I change the value via REST, the subsequent .gets() operation (which returns CASValue) fails with an exception:
{code}
Reconnection due to exception handling a memcached operation on {QA sa=/127.0.0.1:16211, #Rops=1, #Wops=0, #iq=0, topRop=net.spy.memcached.protocol.ascii.GetsOperationImpl@f89761c, topWop=null, toWrite=0, interested=1}. This may be due to an authentication failure.
OperationException: SERVER: SERVER_ERROR java.lang.NullPointerException
at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:123)
at net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.java:130)
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:401)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:333)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:219)
at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1591)
{code}
OTOH, the .get() operation (note the missing "s" in the name) works correctly
> Replacing entry via HotRod which was initially stored via Memcached does not change CAS
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3163
> URL: https://issues.jboss.org/browse/ISPN-3163
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Users might expect that CAS (check-and-set) operation will work even in compatibility mode which is currently not true in the following scenario:
> 1) store a key/value via Memcached
> 2) change the value via HotRod or Embedded
> 3) use Memcached's CAS operation
> In step #3 the memcached client will update the value even though the value was changed by another client in the meantime. The memcached client was supposed to change it only if it had not been changed in the meantime.
> The following test snippet shows the problem:
> {code:java}
> public void testMemcachedPutHotRodEmbbeddedReplaceMemcachedCASTest() throws Exception {
> final String key1 = "5";
> // 1. Put with Memcached
> Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v1");
> assertTrue(f.get(60, TimeUnit.SECONDS));
> CASValue oldValue = cacheFactory.getMemcachedClient().gets(key1);
> // 2. Replace with Hot Rod
> VersionedValue versioned = cacheFactory.getHotRodCache().getVersioned(key1);
> assertTrue(cacheFactory.getHotRodCache().replaceWithVersion(key1, "v2", versioned.getVersion()));
> // 3. Replace with Embedded
> assertTrue(cacheFactory.getEmbeddedCache().replace(key1, "v2", "v3"));
> // 4. Get with Memcached and verify value/CAS
> CASValue newValue = cacheFactory.getMemcachedClient().gets(key1);
> assertEquals("v3", newValue.getValue());
> assertTrue("The version (CAS) should have changed", oldValue.getCas() != newValue.getCas());
> //<---- fails here
> }
> {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
[JBoss JIRA] (ISPN-3163) Replacing entry via HotRod which was initially stored via Memcached does not change CAS
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3163?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3163:
--------------------------------
Description:
Users might expect that CAS (check-and-set) operation will work even in compatibility mode which is currently not true in the following scenario:
1) store a key/value via Memcached
2) change the value via HotRod or Embedded
3) use Memcached's CAS operation
In step #3 the memcached client will update the value even though the value was changed by another client in the meantime. The memcached client was supposed to change it only if it had not been changed in the meantime.
The following test snippet shows the problem:
{code:java}
public void testMemcachedPutHotRodEmbbeddedReplaceMemcachedCASTest() throws Exception {
final String key1 = "5";
// 1. Put with Memcached
Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v1");
assertTrue(f.get(60, TimeUnit.SECONDS));
CASValue oldValue = cacheFactory.getMemcachedClient().gets(key1);
// 2. Replace with Hot Rod
VersionedValue versioned = cacheFactory.getHotRodCache().getVersioned(key1);
assertTrue(cacheFactory.getHotRodCache().replaceWithVersion(key1, "v2", versioned.getVersion()));
// 3. Replace with Embedded
assertTrue(cacheFactory.getEmbeddedCache().replace(key1, "v2", "v3"));
// 4. Get with Memcached and verify value/CAS
CASValue newValue = cacheFactory.getMemcachedClient().gets(key1);
assertEquals("v3", newValue.getValue());
assertTrue("The version (CAS) should have changed", oldValue.getCas() != newValue.getCas());
//<---- fails here
}
{code}
was:
Users might expect that CAS (check-and-set) operation will work even in compatibility mode which is currently not true in the following scenario:
1) store a key/value via Memcached
2) change the value via HotRod or Embedded
3) use Memcached's CAS operation
In step #3 the memcached client will update the value even though the value was changed by another client in the meantime. The memcached client was supposed to change it only if it had not been changed in the meantime.
The following test snippet shows the problem:
{code:java}
public void testMemcachedPutHotRodEmbbeddedReplaceMemcachedCASTest() throws Exception {
final String key1 = "5";
// 1. Put with Memcached
Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v1");
assertTrue(f.get(60, TimeUnit.SECONDS));
CASValue oldValue = cacheFactory.getMemcachedClient().gets(key1);
// 2. Replace with Hot Rod
VersionedValue versioned = cacheFactory.getHotRodCache().getVersioned(key1);
assertTrue(cacheFactory.getHotRodCache().replaceWithVersion(key1, "v2", versioned.getVersion()));
// 3. Replace with Embedded
assertTrue(cacheFactory.getEmbeddedCache().replace(key1, "v2", "v3"));
// 4. Get with Memcached and verify value/CAS
CASValue newValue = cacheFactory.getMemcachedClient().gets(key1);
assertEquals("v3", newValue.getValue());
assertTrue("The version (CAS) should have changed", oldValue.getCas() != newValue.getCas()); //<---- fails here
}
{code}
> Replacing entry via HotRod which was initially stored via Memcached does not change CAS
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3163
> URL: https://issues.jboss.org/browse/ISPN-3163
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Users might expect that CAS (check-and-set) operation will work even in compatibility mode which is currently not true in the following scenario:
> 1) store a key/value via Memcached
> 2) change the value via HotRod or Embedded
> 3) use Memcached's CAS operation
> In step #3 the memcached client will update the value even though the value was changed by another client in the meantime. The memcached client was supposed to change it only if it had not been changed in the meantime.
> The following test snippet shows the problem:
> {code:java}
> public void testMemcachedPutHotRodEmbbeddedReplaceMemcachedCASTest() throws Exception {
> final String key1 = "5";
> // 1. Put with Memcached
> Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v1");
> assertTrue(f.get(60, TimeUnit.SECONDS));
> CASValue oldValue = cacheFactory.getMemcachedClient().gets(key1);
> // 2. Replace with Hot Rod
> VersionedValue versioned = cacheFactory.getHotRodCache().getVersioned(key1);
> assertTrue(cacheFactory.getHotRodCache().replaceWithVersion(key1, "v2", versioned.getVersion()));
> // 3. Replace with Embedded
> assertTrue(cacheFactory.getEmbeddedCache().replace(key1, "v2", "v3"));
> // 4. Get with Memcached and verify value/CAS
> CASValue newValue = cacheFactory.getMemcachedClient().gets(key1);
> assertEquals("v3", newValue.getValue());
> assertTrue("The version (CAS) should have changed", oldValue.getCas() != newValue.getCas());
> //<---- fails here
> }
> {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
[JBoss JIRA] (ISPN-3163) Replacing entry via HotRod which was initially stored via Memcached does not change CAS
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3163:
-----------------------------------
Summary: Replacing entry via HotRod which was initially stored via Memcached does not change CAS
Key: ISPN-3163
URL: https://issues.jboss.org/browse/ISPN-3163
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.3.0.CR1
Reporter: Martin Gencur
Assignee: Galder Zamarreño
Fix For: 5.3.0.Final
Users might expect that CAS (check-and-set) operation will work even in compatibility mode which is currently not true in the following scenario:
1) store a key/value via Memcached
2) change the value via HotRod or Embedded
3) use Memcached's CAS operation
In step #3 the memcached client will update the value even though the value was changed by another client in the meantime. The memcached client was supposed to change it only if it had not been changed in the meantime.
The following test snippet shows the problem:
{code:java}
public void testMemcachedPutHotRodEmbbeddedReplaceMemcachedCASTest() throws Exception {
final String key1 = "5";
// 1. Put with Memcached
Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v1");
assertTrue(f.get(60, TimeUnit.SECONDS));
CASValue oldValue = cacheFactory.getMemcachedClient().gets(key1);
// 2. Replace with Hot Rod
VersionedValue versioned = cacheFactory.getHotRodCache().getVersioned(key1);
assertTrue(cacheFactory.getHotRodCache().replaceWithVersion(key1, "v2", versioned.getVersion()));
// 3. Replace with Embedded
assertTrue(cacheFactory.getEmbeddedCache().replace(key1, "v2", "v3"));
// 4. Get with Memcached and verify value/CAS
CASValue newValue = cacheFactory.getMemcachedClient().gets(key1);
assertEquals("v3", newValue.getValue());
assertTrue("The version (CAS) should have changed", oldValue.getCas() != newValue.getCas()); //<---- fails here
}
{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
[JBoss JIRA] (ISPN-3152) LoadersConfigurationBuilder does not clear existing stores on read()
by Marta Sedlakova (JIRA)
[ https://issues.jboss.org/browse/ISPN-3152?page=com.atlassian.jira.plugin.... ]
Marta Sedlakova commented on ISPN-3152:
---------------------------------------
Thanks Tristan, this workaround seems work fine.
> LoadersConfigurationBuilder does not clear existing stores on read()
> --------------------------------------------------------------------
>
> Key: ISPN-3152
> URL: https://issues.jboss.org/browse/ISPN-3152
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 5.2.1.Final
> Reporter: Marta Sedlakova
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> Hello,
>
> I am upgrading infinispan configuration and I have following problem:
> In old configuration, we use:
> Configuration config;
> JdbmCacheStoreConfig storeConfig = new JdbmCacheStoreConfig();
> storeConfig.setLocation(location);
> storeConfig.setCacheLoaderClassName("org.infinispan.loaders.jdbm.JdbmCacheStore");
> storeConfig.setFetchPersistentState(true);
> storeConfig.setIgnoreModifications(false);
> storeConfig.setPurgeOnStartup(false);
> config = lc.addCacheLoader(storeConfig).build();
>
> manager = new DefaultCacheManager(new GlobalConfiguration(), config);
> Configuration c = manager.getDefaultConfiguration();
> c.setEvictionMaxEntries(maxEntries);
> c.setExpirationLifespan(lifespan);
> manager.defineConfiguration(name, c);
> And this works fine. Now I am updating to new configuration:
> ConfigurationBuilder configuration = new ConfigurationBuilder();
> configuration.invocationBatching().enable();
> JdbmCacheStoreConfigurationBuilder builder = new JdbmCacheStoreConfigurationBuilder(configuration.loaders());
> builder.location(location).fetchPersistentState(true);
> configuration.loaders().addStore(builder);
> manager = new DefaultCacheManager(new GlobalConfigurationBuilder().build(), configuration.build());
>
> And I want to change some properties from previous default configuration for named cache:
>
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.read(manager.getDefaultCacheConfiguration());
> builder.eviction().maxEntries(maxEntries));
> builder.expiration().lifespan(lifespan);
> manager.defineConfiguration(name, builder.build());
> Cache<String, Object> cache = manager.getCache(name);
> cache.start();
>
> But I got following exception:
>
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.loaders.CacheLoaderManagerImpl.start() on object of type CacheLoaderManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:199)
> at org.infinispan.CacheImpl.start(CacheImpl.java:559)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> at eu.ysoft.cache.ifspn.replicator.IfspnReplicationBuffer.start(IfspnReplicationBuffer.java:117)
> at eu.ysoft.cache.replicator.ReplicatorImpl.start(ReplicatorImpl.java:373)
> at eu.ysoft.cache.replicator.ReplicatorImpl.start(ReplicatorImpl.java:233)
> at eu.ysoft.cache.ifspn.replicator.helpers.IfspnReplicationClient.start(IfspnReplicationClient.java:46)
> at eu.ysoft.cache.ifspn.replicator.functional.IfspnTestSimpleReplications.init(IfspnTestSimpleReplications.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:613)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:842)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1166)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1178)
> at org.testng.TestRunner.privateRun(TestRunner.java:757)
> at org.testng.TestRunner.run(TestRunner.java:608)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1158)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1083)
> at org.testng.TestNG.run(TestNG.java:999)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:203)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:111)
> Caused by: org.infinispan.CacheException: Unable to start cache loaders
> at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 42 more
> Caused by: java.lang.Exception: Invalid cache loader configuration!! Only ONE cache loader may have fetchPersistentState set to true. Cache will not start!
> at org.infinispan.loaders.CacheLoaderManagerImpl.createCacheLoader(CacheLoaderManagerImpl.java:324)
> at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:146)
> ... 47 more
>
>
> I need some help how to solve this issue, when we were using the old deprecated configuration, this configuration scenarion works.
> Thanks
> Marta
--
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
[JBoss JIRA] (ISPN-3162) implement a spliterator like interface for parallel traversal of local and replicated cache
by Mathieu Lachance (JIRA)
Mathieu Lachance created ISPN-3162:
--------------------------------------
Summary: implement a spliterator like interface for parallel traversal of local and replicated cache
Key: ISPN-3162
URL: https://issues.jboss.org/browse/ISPN-3162
Project: Infinispan
Issue Type: Feature Request
Components: Core API, Distributed Execution and Map/Reduce, Loaders and Stores
Affects Versions: 5.3.0.CR1
Reporter: Mathieu Lachance
Assignee: Mircea Markus
The backport of ConcurrentHashMapV8 comes with an interesting interface, Spliterator and it's 3 implementations, Key/Value/EntryIterator.
As java 7 is now being more widely adopted, it could be interesting to offer to take advantage of the java ForkJoinPool for the parallel traversal of local and replicated caches where the Infinispan map reduce framework is maybe less suited for.
At term, it could be used to speed up the search in a cache without the need to index it.
--
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