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

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

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.

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.



  was:
According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
on replace() method: CacheEntryModifiedEvent
// EDIT: NOT TRUE, DON'T READ --- on remove() method: CacheEntryRemovedEvent, 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
// EDIT: THIS IS OK --- on remove() method: CacheEntryRemovedEvent ---

EDIT:
I further explored the test CustomClassLoaderListenerTest and found new 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.

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.




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