[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2950:
--------------------------------
Priority: Critical (was: Major)
> In distributed mode cache store data should be read through the main data owner (vs directly from the store)
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2950
> URL: https://issues.jboss.org/browse/ISPN-2950
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Dist cache with a cache store(shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawback:
> - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this)
> - if this is a local cache store, it might contain stale data which would be returned to the user
> - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.)
> This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well.
--
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
[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2950:
-------------------------------------
[~manik]
{quote} Agreed, what's ClusterCacheLoader got to do with this issue? Pls update the description to remove that line. {quote}
Note that I'm talking about the ClusterCacheLoader and not the RemoteCacheLoader.
it won't be needed anymore as we'd always go to the owning nodes first, so the new behaviour would have it "hardcoded" internally.
> In distributed mode cache store data should be read through the main data owner (vs directly from the store)
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2950
> URL: https://issues.jboss.org/browse/ISPN-2950
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Dist cache with a cache store(shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawback:
> - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this)
> - if this is a local cache store, it might contain stale data which would be returned to the user
> - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.)
> This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well.
--
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
[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2950:
-------------------------------------
{quote} Why should the ClusterCacheLoader be deprecated? I think that's totally unrelated, I might still want to load data from a different grid instance, or another cache having a different configuration.{quote}
The ClusterCacheLoader won't help you with that, as it only looks up data *in the same cache* on the remaining members of the cluster. It's the RemoteCacheStore you're after for the use case you mentioned.
> In distributed mode cache store data should be read through the main data owner (vs directly from the store)
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2950
> URL: https://issues.jboss.org/browse/ISPN-2950
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Dist cache with a cache store(shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawback:
> - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this)
> - if this is a local cache store, it might contain stale data which would be returned to the user
> - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.)
> This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well.
--
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
[JBoss JIRA] (ISPN-2951) Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2951?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2951:
-------------------------------------
thanks for reporting this!
as a temporary workaround, you can unregister the domain "by hand".
> Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2951
> URL: https://issues.jboss.org/browse/ISPN-2951
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Environment: JDK Oracle 1.6.0_35
> Reporter: Thomas Mortagne
> Assignee: Mircea Markus
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> When I do something like the following:
> {code:java}
> cacheManager.getCache("test");
> cacheManager.removeCache("test");
> cacheManager.getCache("test");
> {code}
> it fails with the following exception (this exception is not exactly with the code above but it's what is happening):
> {noformat}
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.jmx.CacheJmxRegistration.start() on object of type CacheJmxRegistration
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> 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 org.xwiki.cache.infinispan.internal.InfinispanCache.<init>(InfinispanCache.java:71)
> at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:170)
> at org.xwiki.cache.infinispan.InfinispanCacheTest.testRecreateCache(InfinispanCacheTest.java:62)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jmock.integration.junit4.JUnitRuleMockery$1.evaluate(JUnitRuleMockery.java:49)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=Cache,name="test(local)",manager="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75)
> at org.infinispan.jmx.CacheJmxRegistration.updateDomain(CacheJmxRegistration.java:153)
> at org.infinispan.jmx.CacheJmxRegistration.buildRegistrar(CacheJmxRegistration.java:145)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59)
> at org.infinispan.jmx.CacheJmxRegistration.start(CacheJmxRegistration.java:83)
> 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)
> ... 38 more
> {noformat}
> Note: this was working well with 5.1.8.Final
--
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
[JBoss JIRA] (ISPN-2951) Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2951?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2951:
--------------------------------
Priority: Major (was: Critical)
> Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2951
> URL: https://issues.jboss.org/browse/ISPN-2951
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Environment: JDK Oracle 1.6.0_35
> Reporter: Thomas Mortagne
> Assignee: Mircea Markus
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> When I do something like the following:
> {code:java}
> cacheManager.getCache("test");
> cacheManager.removeCache("test");
> cacheManager.getCache("test");
> {code}
> it fails with the following exception (this exception is not exactly with the code above but it's what is happening):
> {noformat}
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.jmx.CacheJmxRegistration.start() on object of type CacheJmxRegistration
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> 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 org.xwiki.cache.infinispan.internal.InfinispanCache.<init>(InfinispanCache.java:71)
> at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:170)
> at org.xwiki.cache.infinispan.InfinispanCacheTest.testRecreateCache(InfinispanCacheTest.java:62)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jmock.integration.junit4.JUnitRuleMockery$1.evaluate(JUnitRuleMockery.java:49)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=Cache,name="test(local)",manager="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75)
> at org.infinispan.jmx.CacheJmxRegistration.updateDomain(CacheJmxRegistration.java:153)
> at org.infinispan.jmx.CacheJmxRegistration.buildRegistrar(CacheJmxRegistration.java:145)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59)
> at org.infinispan.jmx.CacheJmxRegistration.start(CacheJmxRegistration.java:83)
> 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)
> ... 38 more
> {noformat}
> Note: this was working well with 5.1.8.Final
--
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
[JBoss JIRA] (ISPN-2951) Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2951?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2951:
--------------------------------
Fix Version/s: 5.3.0.Alpha1
5.3.0.Final
> Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2951
> URL: https://issues.jboss.org/browse/ISPN-2951
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Environment: JDK Oracle 1.6.0_35
> Reporter: Thomas Mortagne
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> When I do something like the following:
> {code:java}
> cacheManager.getCache("test");
> cacheManager.removeCache("test");
> cacheManager.getCache("test");
> {code}
> it fails with the following exception (this exception is not exactly with the code above but it's what is happening):
> {noformat}
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.jmx.CacheJmxRegistration.start() on object of type CacheJmxRegistration
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> 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 org.xwiki.cache.infinispan.internal.InfinispanCache.<init>(InfinispanCache.java:71)
> at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:170)
> at org.xwiki.cache.infinispan.InfinispanCacheTest.testRecreateCache(InfinispanCacheTest.java:62)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jmock.integration.junit4.JUnitRuleMockery$1.evaluate(JUnitRuleMockery.java:49)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=Cache,name="test(local)",manager="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75)
> at org.infinispan.jmx.CacheJmxRegistration.updateDomain(CacheJmxRegistration.java:153)
> at org.infinispan.jmx.CacheJmxRegistration.buildRegistrar(CacheJmxRegistration.java:145)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59)
> at org.infinispan.jmx.CacheJmxRegistration.start(CacheJmxRegistration.java:83)
> 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)
> ... 38 more
> {noformat}
> Note: this was working well with 5.1.8.Final
--
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
[JBoss JIRA] (ISPN-2955) Async marshalling executor retry when queue fills
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2955?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2955:
-------------------------------------
+1 for not retrying because of the busy loop. Why not use a CallerRunsPolicy here, after all there's no real reason why the caller should block? (if callers produce too much then FD would take care of this).
> Async marshalling executor retry when queue fills
> -------------------------------------------------
>
> Key: ISPN-2955
> URL: https://issues.jboss.org/browse/ISPN-2955
> Project: Infinispan
> Issue Type: Enhancement
> Components: Marshalling
> Affects Versions: 5.2.5.Final
> Reporter: Manik Surtani
> Assignee: Manik Surtani
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> When using an async transport and async marshalling, an executor is used to process the marshalling task in a separate thread and the caller's thread is allowed to return immediately.
> When the executor's queue fills and the queue cannot accept any more tasks, it throws a {{RejectedExecutionException}}, causing a very bad user/developer experience. A more correct approach to this is to catch the {{RejectedExecutionException}}, block and retry the task submission.
> The end result is that, in the degenerate case (when the executor queue is full) instead of throwing exceptions, those invocations will perform slightly slower.
--
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
[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2956:
-------------------------------------
The versioning case in the code snippet above is very user specific, generally users would want to add a specific value to the cache. Or do you plan to add a version parameter to the putIfAbsent operation itself?
IMO in order to honour the contract of putIfAbsent we should avoid the retry, and simply propagate the exception to the user. The users should expect inconsistencies when working with hotrod as it is now (non-transactional caches), so he can act accordingly: check the value, retry etc.
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: hotrod-java-client, remote-clients
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating 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
[JBoss JIRA] (ISPN-2957) XMLStreamException raised by Parser52.parseInterceptor() when declaring custom interceptor with properties
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2957?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2957:
--------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> XMLStreamException raised by Parser52.parseInterceptor() when declaring custom interceptor with properties
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2957
> URL: https://issues.jboss.org/browse/ISPN-2957
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core API
> Affects Versions: 5.2.1.Final
> Reporter: Alan STS
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> Infinispan 5.2 schema allows to declare a custom interceptor with properties as follows:
> <customInterceptors>
> <interceptor position="LAST" class="com.group.awms.is.resource.dao.infinispan.interceptor.ApplicationInterceptor">
> <properties>
> <property name="cacheActivityName" value="activity" />
> </properties>
> </interceptor>
> </customInterceptors>
> Problem is that method parseInterceptor of class Parser52 does not expect any content for interceptors and the following exception is raised:
> Message: Unexpected element '{urn:infinispan:config:5.2}properties' encountered
> at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:57)
> at org.infinispan.configuration.parsing.ParseUtils.requireNoContent(ParseUtils.java:152)
> at org.infinispan.configuration.parsing.Parser52.parseInterceptor(Parser52.java:1186)
> at org.infinispan.configuration.parsing.Parser52.parseCustomInterceptors(Parser52.java:1148)
> at org.infinispan.configuration.parsing.Parser52.parseCache(Parser52.java:156)
> at org.infinispan.configuration.parsing.Parser52.parseNamedCache(Parser52.java:139)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:106)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:75)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:77)
> ... 40 more
> The Parser class is not in sync with the schema.
--
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
[JBoss JIRA] (ISPN-2957) XMLStreamException raised by Parser52.parseInterceptor() when declaring custom interceptor with properties
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2957?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2957:
--------------------------------
Fix Version/s: 5.3.0.Final
> XMLStreamException raised by Parser52.parseInterceptor() when declaring custom interceptor with properties
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2957
> URL: https://issues.jboss.org/browse/ISPN-2957
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core API
> Affects Versions: 5.2.1.Final
> Reporter: Alan STS
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> Infinispan 5.2 schema allows to declare a custom interceptor with properties as follows:
> <customInterceptors>
> <interceptor position="LAST" class="com.group.awms.is.resource.dao.infinispan.interceptor.ApplicationInterceptor">
> <properties>
> <property name="cacheActivityName" value="activity" />
> </properties>
> </interceptor>
> </customInterceptors>
> Problem is that method parseInterceptor of class Parser52 does not expect any content for interceptors and the following exception is raised:
> Message: Unexpected element '{urn:infinispan:config:5.2}properties' encountered
> at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:57)
> at org.infinispan.configuration.parsing.ParseUtils.requireNoContent(ParseUtils.java:152)
> at org.infinispan.configuration.parsing.Parser52.parseInterceptor(Parser52.java:1186)
> at org.infinispan.configuration.parsing.Parser52.parseCustomInterceptors(Parser52.java:1148)
> at org.infinispan.configuration.parsing.Parser52.parseCache(Parser52.java:156)
> at org.infinispan.configuration.parsing.Parser52.parseNamedCache(Parser52.java:139)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:106)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:75)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:77)
> ... 40 more
> The Parser class is not in sync with the schema.
--
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