[infinispan-issues] [JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode

Different CacheEntryEvents fired in library mode and compatibility mode ----------------------------------------------------------------------- Key: ISPN-3430 URL: https://issues.jboss.org/browse/ISPN-3430 Project: Infinispan Issue Type: Bug Components: Listeners, Remote protocols Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 Reporter: Jiří Holuša Assignee: Galder Zamarreño Fix For: 6.0.0.Beta1, 6.0.0.Final According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode: on replace() method: CacheEntryModifiedEvent But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this: on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent Also tested remote caches via Rest and Memcached. All three ways (HotRod, Rest, Memcached) contains this inconsistency on replace() method. In addition, when operating via Rest, on modifying existing entry via put method, it fires CacheEntryVisitedEvent, which is inconsistent even with the other remote caches. I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes. Summary, In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test. Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent. This is the +1/-1 thing I was talking about. The difference in replace() method between library and compatibility mode remains. I've pulled request with tests for these things. Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.