Perhaps a bogus sentence in BoundedConcurrentHashMap.containsValue()?
by "이희승 (Trustin Lee)"
In BoundedConcurrentHashMap.containsValue(), there are three assignments
whose left-side variable isn't accessed at all:
1) int sum = 0;
2) int c = segments[i].count;
3) int c = segments[i].count; (same with 2 but in a different place)
The first one is apparently safe to remove but I'm not sure about the
others. Is there any reason to retain them, or can we remove them simply?
--
Trustin Lee - http://gleamynode.net/
14 years, 2 months
what happens when an event listener throws an exception
by Mircea Markus
${SUBJECT} ?
This doesn't seem to be specified in the javadoc at the moment. Looking at CacheNotifierImpl it doesn't expect such a thing to happen.
IMO we should handle these exceptions and log them as warn.
One way or the other we should expect this to happen, and document it.
wdyt?
Cheers,
Mircea
14 years, 2 months
Do we need bulk eviction notification?
by "이희승 (Trustin Lee)"
Current BoundedConcurrentHashMap notifies EvictionListener for every
evicted entry. However, as you see from
BoundedConcurrentHashMap.Segment.attemptEviction(..), eviction often
happens in bulk.
If these evicted entries are supposed to be passivated, it is often
beneficial to begin a transaction because it often takes much less time
to call commit() less often. If N entries are evicted:
without bulk eviction:
store.store(e1); -- each store implied a commit()
store.store(..);
store.store(eN);
with bulk eviction:
store.begin(mods(e1, ..., eN), tx, true);
so, what do you think about changing the EvictionListener interface like
this:
interface EvictionListener<K, V> {
void preEvict(K key);
void postEvict(K key, V value);
void preBulkEvict(Set<K> keys);
void postBulkEvict(Map<K, V> entries);
}
abstract class AbstractEvictionListener<K, V>
implements EvictionListener {
void preBulkEvict(Set<K> keys) {
for (K k: keys) { preEvict(k); }
}
void postBulkEvict(Set<K> keys) {
...
}
}
I might be missing something though. Please let me know if there is a
way to achieve similar improvement without this modification.
--
Trustin Lee - http://gleamynode.net/
14 years, 2 months
EvictionListener.preEvict() vs postEvict()
by "이희승 (Trustin Lee)"
Is there a reason why we have two listener methods for eviction? Can we
affect the behavior of the eviction if we do something in preEvict()?
To me, it seems like we cannot and I failed to see what benefits there
are to have the two listener methods.
Also, preEvict() has no value parameter, but the value of the
to-be-evicted entry seems to be always known when preEvict() is called.
Is there a reason why preEvict() doesn't have the value parameter?
I also wonder modifying the EvictionListener interface will affect the
users breaking the backward compatibility with 4.1. I merely thought it
will break the backward compatibility because it's a public interface,
but I realized that it might not be the case while I'm investigating
ISPN-703, which also makes changes in the public interface.
Thanks in advance,
Trustin
--
Trustin Lee - http://gleamynode.net/
14 years, 2 months
Cassandra Cachestore in 4.2 ?
by Tristan Tarrant
Dear all,
since 4.2 is still alpha, and since the Cassandra Cache Store I've committed
to trunk is working quite well, I propose to include it also in the 4.2.x
branch.
The impact on the rest of the tree is minimal (just adding the module to the
pom.xml). I am working on documentation which I will soon add to the Wiki.
What do you think ?
Tristan
14 years, 2 months
Test framework and cleanup
by Manik Surtani
Currently unit tests extending SingleCacheManagerTest or MultipleCacheManagerTest are cleaned up either after every test method or after all of the test methods declared in a test class, based on the value of the "cleanup" field which can be either CleanupPhase.AFTER_TEST or CleanupPhase.AFTER_METHOD. This is typically set in the constructor of a test class. E.g.,
http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/test/j...
To simplify this even further, I have added 2 annotations to the test framework: @CleanupAfterTest and @CleanupAfterMethod. Instead of setting the "cleanup" field in a constructor, you can now just annotate your test class accordingly. E.g.,
@Test (... )
@CleanupAfterMethod
public class MyTest extends SingleCacheManagerTest {
...
}
Note that the "old" pattern of setting "cleanup" will also work; using the annotation just makes tests more concise and readable.
Enjoy
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 2 months
issues with last release (4.2.ALPHA3)
by Mircea Markus
Hi,
4.2.ALPHA3 was mistakenly released from trunk (i.e. it is rather a trunk snapshot release).
Because we port all our changes from 4.2 to trunk on each commit, you most likely won't be affected by this, unless:
- if data are store with 4.2.0.ALPAH3, you might not read it properly with another 4.2.x version
- you are using Apache avro based marshaller which is only developed on trunk and won't work on next alpha relese.
Sorry for the trouble caused!
Mircea
14 years, 2 months
Indentation and License header
by "이희승 (Trustin Lee)"
Hi folks,
I found some files with no license header or with tab indentation in our
repository. Would you mind if I update them? It might cause conflicts
during merge process if you have complicated pending changes in your
working copy.
--
Trustin Lee - http://gleamynode.net/
14 years, 2 months
