[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:all-tabpanel ]

Galder Zamarreño updated ISPN-3430:
-----------------------------------

    Git Pull Request: https://github.com/infinispan/infinispan/pull/2021, https://github.com/infinispan/infinispan/pull/2028  (was: https://github.com/infinispan/infinispan/pull/2021)

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

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