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

[Galder Zamarreño (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799402#comment-12799402 ] 

Galder Zamarreño commented on ISPN-3430:
----------------------------------------

{quote}
Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
{quote}

^ TBH, cache entry modified event should only be fired when an entry is updated (not when inserted or deleted), but we won't be changing the behaviour in the near future to avoid breaking logic users have built around this. In fact, if no cache entry modified event was thrown on creation, you'd not be able to get a callback with the added entry, as highlighted in http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010272.html. Bringing an entry back to memory from a cache store could be considered as a cache entry modified event, given the loose meaning we have on this event. I don't think we should change this at this point without a full review of events. There's a fair few other inconsistencies around...

The improvements you've made to CustomClassLoaderListenerTest are good though, apart from that expectation error, which I'll switch when committing fix for this.
                
> 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: 6.0.0.Alpha2
>            Reporter: Jiří Holuša
>            Assignee: Galder Zamarreño
>
>  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.

--
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