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

[Jiří Holuša (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiří Holuša updated ISPN-3430:
------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/infinispan/infinispan/pull/2021


This pull request contains tests to several bugs/inconsistent things related to CacheEntryEvents in library mode and mainly in compatibility mode.

Fixes test for library mode listeners where methods remove() and get() (get() after eviction) fires different events that the test says (via comments).

Main part is directed to compatibility mode where it tests if correct events are fired, successfully propagated to embedded cache and contain correct readable data.
The assumption "which events should be fired" was made based on library mode, so it would be consistent.
All remote caches (HotRot, Memcached, Rest) fire CacheEntryVisitedEvent on replace() which is inconsistent with library mode. Additionally, via Rest cache, it fires CacheEntryVisitedEvent when simply modifying entry via put() which is inconsistent even with other remote caches.

These tests are supposed to fail over these things.

                
> 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