[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2575:
--------------------------------
Assignee: Adrian Nistor (was: Sanne Grinovero)
> KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2575
> URL: https://issues.jboss.org/browse/ISPN-2575
> Project: Infinispan
> Issue Type: Enhancement
> Components: Querying
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Attachments: ClusteredCacheTest.java
>
>
> The case is the following:
> I have a clustered cache on which I want to perform a search. I'm doing the following:
> I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception:
> java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
> When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager.
> The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer()
--
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
1 week, 4 days
[JBoss JIRA] (ISPN-3457) Infinispan error running on IBM JDK
by Luis Montoya (JIRA)
[ https://issues.jboss.org/browse/ISPN-3457?page=com.atlassian.jira.plugin.... ]
Luis Montoya updated ISPN-3457:
-------------------------------
Description:
I created a sample application using infinispan on standar JDK (Sun/Oracle). This app works fine using this JDK.
I tried to run the app on IBM JDK (the needed for WAS), but I get the below error:
org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:129)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:276)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:246)
at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.createCacheManagerProgramatically(AbstractNode.java:41)
at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.<init>(AbstractNode.java:62)
at org.infinispan.quickstart.clusteredcache.replication.Node0.main(Node0.java:32)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.topology.LocalTopologyManagerImpl.inject(org.infinispan.remoting.transport.Transport,java.util.concurrent.ExecutorService,org.infinispan.factories.GlobalComponentRegistry,org.infinispan.util.TimeService) on object of type LocalTopologyManagerImpl with parameters [org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.factories.GlobalComponentRegistry@9fd5a559, org.infinispan.util.DefaultTimeService@725adace]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:188)
at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:229)
at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:253)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:125)
... 5 more
Caused by: java.lang.IllegalArgumentException: discrepancia en el tipo de argumento
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 13 more
It seems that a method which is being invoked through reflection is receiving incorrectly the first parameter, which should be a org.infinispan.remoting.transport.Transport instance, but it is receiving a org.infinispan.executors.LazyInitializingExecutorService@96d7b55b instance
The code which launch the error is the next:
new DefaultCacheManager(
GlobalConfigurationBuilder.defaultClusteredBuilder().globalJmxStatistics().allowDuplicateDomains(true)
.transport().addProperty("configurationFile", "jgroups.xml")
.build(),
new ConfigurationBuilder()
.clustering().cacheMode(CacheMode.REPL_SYNC)
.build()
);
Making a review and debug of the code, the next behavior was seen which produce the error:
if a map called map contains something like this {1=some.class.type}, and you try to get a value using the 0 as the key ( map.get(0), it doens't return null rather it returns the value for the 1 key, it means, for map.get(0) it returns "some.class.type", as if map.get(1) was called)
Also, when the contains method of Map interface is called ( map.contains(0)), it returns true, which is incorrect because the map only has the 1 key
This behavior is happening on this class and method:
class: org.infinispan.factories.components.ComponentMetadata$InjectMetadata
methods: getParameterName, isParameterNameSet
was:
I created a sample application using infinispan on standar JDK (Sun/Oracle). This app works fine using this JDK.
I tried to run the app on IBM JDK (the needed for WAS), but I get the below error:
org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:129)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:276)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:246)
at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.createCacheManagerProgramatically(AbstractNode.java:41)
at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.<init>(AbstractNode.java:62)
at org.infinispan.quickstart.clusteredcache.replication.Node0.main(Node0.java:32)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.topology.LocalTopologyManagerImpl.inject(org.infinispan.remoting.transport.Transport,java.util.concurrent.ExecutorService,org.infinispan.factories.GlobalComponentRegistry,org.infinispan.util.TimeService) on object of type LocalTopologyManagerImpl with parameters [org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.factories.GlobalComponentRegistry@9fd5a559, org.infinispan.util.DefaultTimeService@725adace]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:188)
at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:229)
at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:253)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:125)
... 5 more
Caused by: java.lang.IllegalArgumentException: discrepancia en el tipo de argumento
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 13 more
It seems that a method which is being invoked through reflection is receiving incorrectly the first parameter, which should be a org.infinispan.remoting.transport.Transport instance, but it is receiving a org.infinispan.executors.LazyInitializingExecutorService@96d7b55b instance
The code which launch the error is the next:
new DefaultCacheManager(
GlobalConfigurationBuilder.defaultClusteredBuilder().globalJmxStatistics().allowDuplicateDomains(true)
.transport().addProperty("configurationFile", "jgroups.xml")
.build(),
new ConfigurationBuilder()
.clustering().cacheMode(CacheMode.REPL_SYNC)
.build()
);
Making a review and debug of the code, the next behavior was saw which produce the error:
if a map called map contains something like this {1=some.class.type}, and you try to get a value using the 0 as the key ( map.get(0), it doens't return null rather it returns the value for the 1 key, it means, for map.get(0) it returns "some.class.type", as if map.get(1) was called)
Also, when the contains method of Map interface is called ( map.contains(0)), it returns true, which is incorrect because the map only has the 1 key
This behavior is happening on this class and method:
class: org.infinispan.factories.components.ComponentMetadata$InjectMetadata
methods: getParameterName, isParameterNameSet
> Infinispan error running on IBM JDK
> -----------------------------------
>
> Key: ISPN-3457
> URL: https://issues.jboss.org/browse/ISPN-3457
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Environment: WAS 8.0.0.6 JDK, Windows 7 Professional
> Reporter: Luis Montoya
> Assignee: Mircea Markus
> Fix For: 6.0.0.Alpha3
>
>
> I created a sample application using infinispan on standar JDK (Sun/Oracle). This app works fine using this JDK.
>
> I tried to run the app on IBM JDK (the needed for WAS), but I get the below error:
>
> org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:129)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:276)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:246)
> at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.createCacheManagerProgramatically(AbstractNode.java:41)
> at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.<init>(AbstractNode.java:62)
> at org.infinispan.quickstart.clusteredcache.replication.Node0.main(Node0.java:32)
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.topology.LocalTopologyManagerImpl.inject(org.infinispan.remoting.transport.Transport,java.util.concurrent.ExecutorService,org.infinispan.factories.GlobalComponentRegistry,org.infinispan.util.TimeService) on object of type LocalTopologyManagerImpl with parameters [org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.factories.GlobalComponentRegistry@9fd5a559, org.infinispan.util.DefaultTimeService@725adace]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:188)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:229)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:253)
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:125)
> ... 5 more
> Caused by: java.lang.IllegalArgumentException: discrepancia en el tipo de argumento
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:600)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 13 more
>
>
> It seems that a method which is being invoked through reflection is receiving incorrectly the first parameter, which should be a org.infinispan.remoting.transport.Transport instance, but it is receiving a org.infinispan.executors.LazyInitializingExecutorService@96d7b55b instance
>
> The code which launch the error is the next:
>
>
> new DefaultCacheManager(
> GlobalConfigurationBuilder.defaultClusteredBuilder().globalJmxStatistics().allowDuplicateDomains(true)
> .transport().addProperty("configurationFile", "jgroups.xml")
> .build(),
> new ConfigurationBuilder()
> .clustering().cacheMode(CacheMode.REPL_SYNC)
> .build()
> );
> Making a review and debug of the code, the next behavior was seen which produce the error:
> if a map called map contains something like this {1=some.class.type}, and you try to get a value using the 0 as the key ( map.get(0), it doens't return null rather it returns the value for the 1 key, it means, for map.get(0) it returns "some.class.type", as if map.get(1) was called)
> Also, when the contains method of Map interface is called ( map.contains(0)), it returns true, which is incorrect because the map only has the 1 key
> This behavior is happening on this class and method:
> class: org.infinispan.factories.components.ComponentMetadata$InjectMetadata
> methods: getParameterName, isParameterNameSet
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3457) Infinispan error running on IBM JDK
by Luis Montoya (JIRA)
Luis Montoya created ISPN-3457:
----------------------------------
Summary: Infinispan error running on IBM JDK
Key: ISPN-3457
URL: https://issues.jboss.org/browse/ISPN-3457
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 6.0.0.Alpha3
Environment: WAS 8.0.0.6 JDK, Windows 7 Professional
Reporter: Luis Montoya
Assignee: Mircea Markus
Fix For: 6.0.0.Alpha3
I created a sample application using infinispan on standar JDK (Sun/Oracle). This app works fine using this JDK.
I tried to run the app on IBM JDK (the needed for WAS), but I get the below error:
org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:129)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:276)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:246)
at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.createCacheManagerProgramatically(AbstractNode.java:41)
at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.<init>(AbstractNode.java:62)
at org.infinispan.quickstart.clusteredcache.replication.Node0.main(Node0.java:32)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.topology.LocalTopologyManagerImpl.inject(org.infinispan.remoting.transport.Transport,java.util.concurrent.ExecutorService,org.infinispan.factories.GlobalComponentRegistry,org.infinispan.util.TimeService) on object of type LocalTopologyManagerImpl with parameters [org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.factories.GlobalComponentRegistry@9fd5a559, org.infinispan.util.DefaultTimeService@725adace]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:188)
at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:229)
at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:253)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:125)
... 5 more
Caused by: java.lang.IllegalArgumentException: discrepancia en el tipo de argumento
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 13 more
It seems that a method which is being invoked through reflection is receiving incorrectly the first parameter, which should be a org.infinispan.remoting.transport.Transport instance, but it is receiving a org.infinispan.executors.LazyInitializingExecutorService@96d7b55b instance
The code which launch the error is the next:
new DefaultCacheManager(
GlobalConfigurationBuilder.defaultClusteredBuilder().globalJmxStatistics().allowDuplicateDomains(true)
.transport().addProperty("configurationFile", "jgroups.xml")
.build(),
new ConfigurationBuilder()
.clustering().cacheMode(CacheMode.REPL_SYNC)
.build()
);
Making a review and debug of the code, the next behavior was saw which produce the error:
if a map called map contains something like this {1=some.class.type}, and you try to get a value using the 0 as the key ( map.get(0), it doens't return null rather it returns the value for the 1 key, it means, for map.get(0) it returns "some.class.type", as if map.get(1) was called)
Also, when the contains method of Map interface is called ( map.contains(0)), it returns true, which is incorrect because the map only has the 1 key
This behavior is happening on this class and method:
class: org.infinispan.factories.components.ComponentMetadata$InjectMetadata
methods: getParameterName, isParameterNameSet
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load
by Lukasz Szelag (JIRA)
[ https://issues.jboss.org/browse/ISPN-3455?page=com.atlassian.jira.plugin.... ]
Lukasz Szelag commented on ISPN-3455:
-------------------------------------
This issue is also present in the latest version (6.0.0.Alpha3).
> Cache replication not warranted under load
> ------------------------------------------
>
> Key: ISPN-3455
> URL: https://issues.jboss.org/browse/ISPN-3455
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha3
> Environment: JSE 1.6.0_45; Windows 7
> Reporter: Lukasz Szelag
> Assignee: Mircea Markus
> Attachments: infinispan.zip
>
>
> Problem:
> When running a replicated cache and repeatedly calling a cacheable method (using Spring cache abstraction), Infinispan enters an infinite replication loop. This can be confirmed by observing replication counts growing over time, where there are no cache misses.
> Expected behavior:
> Caches shouldn't be replicated when there is a cache hit.
> Test case:
> - 3 cluster members; asynchronous replication with a replication queue
> - a cacheable method is executed repeatedly using 2 different keys
> Notes:
> - for some reason, this issue only occurs when using Enum arguments for a cache key; I was not able to replicate this when using int or String types (see com.designamus.infinispan.Main.works())
> - the behavior is not deterministic (random), which points to a race condition
> - the problem does not seem to be related to the Spring's default cache key generator; I was able to reproduce the same behavior with a custom cache key generator, which was thread-safe
> - the cacheable method is executed only twice (once both keys are stored in the cache); subsequent invocations retrieve stored values from the cache; this can be confirmed by inspecting the log file
> - the cache doesn't expire and entries are not evicted
> - the memory usage grows over time, eventually causing OOM on a heavily loaded system
> - since the issue is random in nature it may take a 3-4 attempts to reproduce it; I was successful in reproducing this behavior numerous times
> Steps to reproduce:
> 1. Build a test project (mvn clean compile)
> 2. Execute /run.sh (this will spawn 3 JVMs)
> 3. Start JConsole to monitor 3 cluster members (jconsole localhost:17001 localhost:17002 localhost:17003)
> 4. Monitor "replicationCount" attribute under RpcManager for cache "MyCache" for all JVMs (see /replication-counts.png)
> 5. Observe that replication counts grow over time
> 6. Observe that all caches are of size 2 and there are no cache misses (see /cache-statistics.png)
> If the issue cannot be reproduced (replication counts stay at the same level):
> 5. Terminate all 3 JVM processes (as a convenience you can execute /stop.sh)
> 6. Repeat steps 2 through 5 above
> When testing the above scenario using a distributed mode, I observed some other anomalies (i.e. the cacheable method was executed multiple times, as if the value was not there). While this may be related, it deserves a separate JIRA.
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load
by Lukasz Szelag (JIRA)
[ https://issues.jboss.org/browse/ISPN-3455?page=com.atlassian.jira.plugin.... ]
Lukasz Szelag updated ISPN-3455:
--------------------------------
Affects Version/s: 6.0.0.Alpha3
> Cache replication not warranted under load
> ------------------------------------------
>
> Key: ISPN-3455
> URL: https://issues.jboss.org/browse/ISPN-3455
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha3
> Environment: JSE 1.6.0_45; Windows 7
> Reporter: Lukasz Szelag
> Assignee: Mircea Markus
> Attachments: infinispan.zip
>
>
> Problem:
> When running a replicated cache and repeatedly calling a cacheable method (using Spring cache abstraction), Infinispan enters an infinite replication loop. This can be confirmed by observing replication counts growing over time, where there are no cache misses.
> Expected behavior:
> Caches shouldn't be replicated when there is a cache hit.
> Test case:
> - 3 cluster members; asynchronous replication with a replication queue
> - a cacheable method is executed repeatedly using 2 different keys
> Notes:
> - for some reason, this issue only occurs when using Enum arguments for a cache key; I was not able to replicate this when using int or String types (see com.designamus.infinispan.Main.works())
> - the behavior is not deterministic (random), which points to a race condition
> - the problem does not seem to be related to the Spring's default cache key generator; I was able to reproduce the same behavior with a custom cache key generator, which was thread-safe
> - the cacheable method is executed only twice (once both keys are stored in the cache); subsequent invocations retrieve stored values from the cache; this can be confirmed by inspecting the log file
> - the cache doesn't expire and entries are not evicted
> - the memory usage grows over time, eventually causing OOM on a heavily loaded system
> - since the issue is random in nature it may take a 3-4 attempts to reproduce it; I was successful in reproducing this behavior numerous times
> Steps to reproduce:
> 1. Build a test project (mvn clean compile)
> 2. Execute /run.sh (this will spawn 3 JVMs)
> 3. Start JConsole to monitor 3 cluster members (jconsole localhost:17001 localhost:17002 localhost:17003)
> 4. Monitor "replicationCount" attribute under RpcManager for cache "MyCache" for all JVMs (see /replication-counts.png)
> 5. Observe that replication counts grow over time
> 6. Observe that all caches are of size 2 and there are no cache misses (see /cache-statistics.png)
> If the issue cannot be reproduced (replication counts stay at the same level):
> 5. Terminate all 3 JVM processes (as a convenience you can execute /stop.sh)
> 6. Repeat steps 2 through 5 above
> When testing the above scenario using a distributed mode, I observed some other anomalies (i.e. the cacheable method was executed multiple times, as if the value was not there). While this may be related, it deserves a separate JIRA.
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Radoslav Husar <rhusar(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Correcting documentation related fields: should be documented as fixed issue.
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load
by Lukasz Szelag (JIRA)
[ https://issues.jboss.org/browse/ISPN-3455?page=com.atlassian.jira.plugin.... ]
Lukasz Szelag commented on ISPN-3455:
-------------------------------------
In our system (6 clustered nodes), the replication counts continue to grow rapidly even after there is *no caching activity at all* (initially, the caches are being populated as data is being processed). For example, there are only 18 entries in the cache, whereas the replication count is close to 1 million. This eventually causes system going out of memory with a 20 GB heap.
> Cache replication not warranted under load
> ------------------------------------------
>
> Key: ISPN-3455
> URL: https://issues.jboss.org/browse/ISPN-3455
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.3.0.Final
> Environment: JSE 1.6.0_45; Windows 7
> Reporter: Lukasz Szelag
> Assignee: Mircea Markus
> Attachments: infinispan.zip
>
>
> Problem:
> When running a replicated cache and repeatedly calling a cacheable method (using Spring cache abstraction), Infinispan enters an infinite replication loop. This can be confirmed by observing replication counts growing over time, where there are no cache misses.
> Expected behavior:
> Caches shouldn't be replicated when there is a cache hit.
> Test case:
> - 3 cluster members; asynchronous replication with a replication queue
> - a cacheable method is executed repeatedly using 2 different keys
> Notes:
> - for some reason, this issue only occurs when using Enum arguments for a cache key; I was not able to replicate this when using int or String types (see com.designamus.infinispan.Main.works())
> - the behavior is not deterministic (random), which points to a race condition
> - the problem does not seem to be related to the Spring's default cache key generator; I was able to reproduce the same behavior with a custom cache key generator, which was thread-safe
> - the cacheable method is executed only twice (once both keys are stored in the cache); subsequent invocations retrieve stored values from the cache; this can be confirmed by inspecting the log file
> - the cache doesn't expire and entries are not evicted
> - the memory usage grows over time, eventually causing OOM on a heavily loaded system
> - since the issue is random in nature it may take a 3-4 attempts to reproduce it; I was successful in reproducing this behavior numerous times
> Steps to reproduce:
> 1. Build a test project (mvn clean compile)
> 2. Execute /run.sh (this will spawn 3 JVMs)
> 3. Start JConsole to monitor 3 cluster members (jconsole localhost:17001 localhost:17002 localhost:17003)
> 4. Monitor "replicationCount" attribute under RpcManager for cache "MyCache" for all JVMs (see /replication-counts.png)
> 5. Observe that replication counts grow over time
> 6. Observe that all caches are of size 2 and there are no cache misses (see /cache-statistics.png)
> If the issue cannot be reproduced (replication counts stay at the same level):
> 5. Terminate all 3 JVM processes (as a convenience you can execute /stop.sh)
> 6. Repeat steps 2 through 5 above
> When testing the above scenario using a distributed mode, I observed some other anomalies (i.e. the cacheable method was executed multiple times, as if the value was not there). While this may be related, it deserves a separate JIRA.
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3389?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3389:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1998, https://github.com/infinispan/infinispan/pull/2038
> Forwarded transactions can remain stale after state transfer
> ------------------------------------------------------------
>
> Key: ISPN-3389
> URL: https://issues.jboss.org/browse/ISPN-3389
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table.
> The chain of events is as follows:
> 1. New topology comes in as part of a view change.
> 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks.
> 3. Tx forwarded to new owner before the local lock is acquired and registered with the transaction.
> 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners.
> This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key.
> This easily happens with pessimistic caches, though I have seen it happen with optimistic caches (there is a delta between the transaction being created and the lock registration).
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load
by Lukasz Szelag (JIRA)
[ https://issues.jboss.org/browse/ISPN-3455?page=com.atlassian.jira.plugin.... ]
Lukasz Szelag updated ISPN-3455:
--------------------------------
Attachment: infinispan.zip
A test project to reproduce the issue.
> Cache replication not warranted under load
> ------------------------------------------
>
> Key: ISPN-3455
> URL: https://issues.jboss.org/browse/ISPN-3455
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.3.0.Final
> Environment: JSE 1.6.0_45; Windows 7
> Reporter: Lukasz Szelag
> Assignee: Mircea Markus
> Attachments: infinispan.zip
>
>
> Problem:
> When running a replicated cache and repeatedly calling a cacheable method (using Spring cache abstraction), Infinispan enters an infinite replication loop. This can be confirmed by observing replication counts growing over time, where there are no cache misses.
> Expected behavior:
> Caches shouldn't be replicated when there is a cache hit.
> Test case:
> - 3 cluster members; asynchronous replication with a replication queue
> - a cacheable method is executed repeatedly using 2 different keys
> Notes:
> - for some reason, this issue only occurs when using Enum arguments for a cache key; I was not able to replicate this when using int or String types (see com.designamus.infinispan.Main.works())
> - the behavior is not deterministic (random), which points to a race condition
> - the problem does not seem to be related to the Spring's default cache key generator; I was able to reproduce the same behavior with a custom cache key generator, which was thread-safe
> - the cacheable method is executed only twice (once both keys are stored in the cache); subsequent invocations retrieve stored values from the cache; this can be confirmed by inspecting the log file
> - the cache doesn't expire and entries are not evicted
> - the memory usage grows over time, eventually causing OOM on a heavily loaded system
> - since the issue is random in nature it may take a 3-4 attempts to reproduce it; I was successful in reproducing this behavior numerous times
> Steps to reproduce:
> 1. Build a test project (mvn clean compile)
> 2. Execute /run.sh (this will spawn 3 JVMs)
> 3. Start JConsole to monitor 3 cluster members (jconsole localhost:17001 localhost:17002 localhost:17003)
> 4. Monitor "replicationCount" attribute under RpcManager for cache "MyCache" for all JVMs (see /replication-counts.png)
> 5. Observe that replication counts grow over time
> 6. Observe that all caches are of size 2 and there are no cache misses (see /cache-statistics.png)
> If the issue cannot be reproduced (replication counts stay at the same level):
> 5. Terminate all 3 JVM processes (as a convenience you can execute /stop.sh)
> 6. Repeat steps 2 through 5 above
> When testing the above scenario using a distributed mode, I observed some other anomalies (i.e. the cacheable method was executed multiple times, as if the value was not there). While this may be related, it deserves a separate JIRA.
--
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
12 years, 2 months