Is this a bug?
Hello,
I'm using Infinispan 6.0.2.Final with eviction=true, passivation=false and write-behind options
With this configuration the changes(put,remove, etc.) are supposed to be queued and stored asynchronously.
and, duplicated modification for same key will be merged, and stored just once.
However, this is not what I have observed.
And here is what I found so far.
I ran a test code that contain a for loop which put random value of a key named "KEY".
Then, I counted the number of db store operations, it was exactly 1000.(which means no merging operation happened)
Here is the test code.
private static void startTest() {
for(int i=0; i<1000; i++) {
cache.put("KEY", generateValue(1024*1024));
}
}
static Random random = new Random(System.currentTimeMillis());
private static byte[] generateValue(int size) {
byte[] result = new byte[size];
random.nextBytes(result);
return result;
}
Then I did some more test by modifying the infinispan-core source.
I checked the size of org.infinispan.persistence.async.State.modifications and it was increased whenever cache.put() operation called.
It was because the ConcurrentMap<Object, Modification> for the org.infinispan.persistence.async.State.modifications variable cannot distinguish byte[] type as key.
(I guess this is becuase the AnyEquivalence object for the map is for 'Object' type, hence cannot distinguish byte[] key.)
The following is where the ConcurrentMap<Object, Modification> is created.
package org.infinispan.persistence.async;
import net.jcip.annotations.GuardedBy;
public class AsyncCacheWriter extends DelegatingCacheWriter {
....
State newState(boolean clear, State next) {
ConcurrentMap<Object, Modification> map = CollectionFactory.makeConcurrentMap(64, concurrencyLevel); <- EquivalentConcurrentHashMapV8 returned.
return new State(clear, map, next);
}
....
}
Is this normal operation? or a bug?
If this is normal, it could cause serious performance and memory problem..
