Its easier to run everything from command line for two reason I can
think of:
- everyone has same env to compare results with you
- it is all ready to go
See
All,
I am trying to test some changes that I made using Eclipse and the
TestNG plugin. I am not familiar with TestNG. Are there any settings
that I should make? Any ideas?
java.lang.OutOfMemoryError: Java heap space
at
org.infinispan.util.concurrent.BoundedConcurrentHashMap$HashEntry.newArray(_BoundedConcurrentHashMap.java:295_)
at
org.infinispan.util.concurrent.BoundedConcurrentHashMap$Segment.<init>(_BoundedConcurrentHashMap.java:898_)
at
org.infinispan.util.concurrent.BoundedConcurrentHashMap.<init>(_BoundedConcurrentHashMap.java:1367_)
at
org.infinispan.container.DefaultDataContainer.<init>(_DefaultDataContainer.java:78_)
at
org.infinispan.container.DefaultDataContainer.<init>(_DefaultDataContainer.java:47_)
at
org.infinispan.container.DefaultDataContainer.unBoundedDataContainer(_DefaultDataContainer.java:93_)
at
org.infinispan.factories.DataContainerFactory.construct(_DataContainerFactory.java:53_)
at
org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(_AbstractComponentRegistry.java:315_)
at
org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(_AbstractComponentRegistry.java:251_)
at
org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(_AbstractComponentRegistry.java:840_)
at
org.infinispan.factories.AbstractComponentRegistry.registerComponent(_AbstractComponentRegistry.java:225_)
at
org.infinispan.factories.ComponentRegistry.registerComponent(_ComponentRegistry.java:120_)
at
org.infinispan.factories.AbstractComponentRegistry.registerComponent(_AbstractComponentRegistry.java:192_)
at
org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(_AbstractComponentRegistry.java:323_)
at
org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(_AbstractComponentRegistry.java:251_)
at
org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(_AbstractComponentRegistry.java:840_)
at
org.infinispan.factories.AbstractComponentRegistry.registerComponent(_AbstractComponentRegistry.java:225_)
at
org.infinispan.factories.ComponentRegistry.registerComponent(_ComponentRegistry.java:120_)
at
org.infinispan.factories.AbstractComponentRegistry.registerComponent(_AbstractComponentRegistry.java:192_)
at
org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(_AbstractComponentRegistry.java:323_)
at
org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(_AbstractComponentRegistry.java:251_)
at
org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(_AbstractComponentRegistry.java:840_)
at
org.infinispan.factories.AbstractComponentRegistry.registerComponent(_AbstractComponentRegistry.java:225_)
at
org.infinispan.factories.ComponentRegistry.registerComponent(_ComponentRegistry.java:120_)
at
org.infinispan.factories.AbstractComponentRegistry.registerComponent(_AbstractComponentRegistry.java:192_)
at
org.infinispan.factories.InternalCacheFactory.bootstrap(_InternalCacheFactory.java:92_)
at
org.infinispan.factories.InternalCacheFactory.createAndWire(_InternalCacheFactory.java:78_)
at
org.infinispan.factories.InternalCacheFactory.createCache(_InternalCacheFactory.java:62_)
at
org.infinispan.manager.DefaultCacheManager.createCache(_DefaultCacheManager.java:510_)
at
org.infinispan.manager.DefaultCacheManager.getCache(_DefaultCacheManager.java:440_)
at
org.infinispan.manager.DefaultCacheManager.getCache(_DefaultCacheManager.java:409_)
at
org.infinispan.config.ConfigurationValidationTest.testDefaultMemoryGuardConfiguration(_ConfigurationValidationTest.java:100_)
-----Original Message-----
*From:* infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] *On Behalf Of
*Vladimir Blagojevic
*Sent:* Friday, January 14, 2011 11:05 AM
*To:* infinispan -Dev List
*Subject:* Re: [infinispan-dev] ISPN-863 - Thoughts / Questions
Hey David,
First of all kudos for taking on such a non-trivial task!
On 11-01-14 12:22 AM, david marion wrote:
1.Modify configuration in some way so that the following can be specified:
a.The percentage value of used JVM memory (i.e. 95) at which entries
should be evicted to try and avoid an OOM error.
b.The number of items that should be evicted when memory reaches this
threshold
2.Modify LRU and LIRS Eviction class so that the accessQueue member
can be accessed by the new Eviction class so that two access queues
don't have to be maintained.
3.Create a new Eviction class, a subclass of LIRS, where the
accessQueue is used from the Eviction strategy the user specifies and
the for loop in the execute method is exited when the evicted set
equals value from 1.b above.
4.Modify DataContainerFactory.construct() to call
DefaultDataContainer.boundedDataContainer() regardless of eviction
policy. This will always create a BoundedConcurrentHashMap
I don't think you have to extend LRU and LIRS, as long as you
implement EvictionPolicy you are fullfilling the contract. What
extending LRU and LIRS can do is give you some order in selecting
proper elements for eviction. I think the precise technical term in
research literature is "eviction precision".
1.
2.Create an instance of the new Eviction class in each segment.
3.Modify BoundedConcurrentHashMap.Segment put and replace methods such
that when new values are going to be put into the Segment, the memory
usage is checked and the execute method is called on the new Eviction
class.
Sounds right!
1.
Questions:
1.What are the implications of using a BoundedConcurrentHashMap
instead of a ConcurrentHashMap when maxEntries is set to -1?
I think none except you turn on eviction by using
BoundedConcurrentHashMap.
1.
Thoughts
1.This will not guarantee that an OOM error does not occur. It will
attempt to guard against an OOM caused by putting new values into the
cache. This will probably be more effective when the cache is being
used in client/server mode, and less effective when used in embedded
mode as to other code running in the JVM.
-- Dave Marion
Cheers,
Vladimir
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev