[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
11 years, 3 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
11 years, 3 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
11 years, 3 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
11 years, 3 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
11 years, 3 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
11 years, 3 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
11 years, 3 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
11 years, 3 months
[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load
by Lukasz Szelag (JIRA)
Lukasz Szelag created ISPN-3455:
-----------------------------------
Summary: 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
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
11 years, 3 months