[infinispan-dev] Feedback and requests on clustered and remote listeners

[Galder Zamarreño]

On 24 Sep 2014, at 09:10, Radim Vansa <rvansa at redhat.com> wrote:

> On 09/24/2014 08:16 AM, Galder Zamarreño wrote:
>> On 23 Sep 2014, at 19:02, William Burns <mudokonman at gmail.com> wrote:
>> 
>>> On Tue, Sep 23, 2014 at 12:20 PM, Galder Zamarreño <galder at redhat.com> wrote:
>>>> On 23 Sep 2014, at 14:53, Mircea Markus <mmarkus at redhat.com> wrote:
>>>> 
>>>>> On Sep 23, 2014, at 15:18, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>>> 
>>>>>>> I am not sold on this as it seems pretty trivial to decipher which
>>>>>>> operation is which and the information would be present on the
>>>>>>> javadocs as well.
>>>>>> I very strongly disagree. Cf the other thread with Radim 's comment on topology error.
>>>>>> And think about *future* evolutions. The enum would make that much safer. In the bin enum world you would have to introduce a new YetAnotherKeyValueFilter interface :)
>>>>> Nicer than an enum would be an explicit method, e.g. handlePut/handleDelete/handleCreate/handleUpdate, as these would also receive the appropriate param list.
>>>> ^ Hmmmmm, not sure I like that. If you look at the remote event blog posts, you’ll see that I use create/modify/remove annotations and then the parameter to the callback varies depending on whether you had converter applied to it or not. IOW, without a converter, a created event parameter is a ClientCacheEntryCreatedEvent, whereas with a converter, the parameter is a ClientCacheEntryCustomEvent. Two different types of events for the same event type. If you did it with explicit methods, you’d have to duplicate them for custom events.
>>> This is for embedded and is done in the filter and converter (not in
>>> the listener).  Unless I am missing something this shouldn't directly
>>> affect the client methods.
>> Ah ok.
>> 
>>>>> Of course this means moving away from the KeyValueFilter to an UpdateFilter (good name, Radim) used only for cluster listeners.
>>>> I don’t like the name actually. I associate update with modifications, and in similar vein, inserts with creation and delete with removals.
>>> What would you suggest?  A few things I thought of quickly:
>>> CacheOperationFilter, CacheEventFilter, CacheWriteFilter - the only
>>> reason I preface Cache is because we have CacheManager events as well.
>> Maybe CacheEventFilter...
> 
> Does expiration trigger clustered listeners?

Expiration events are not there yet: https://issues.jboss.org/browse/ISPN-694

It’s assigned to me but I’ve had my hands full with HR 2.0 related stuff...

> 'Event' sounds quite 
> generic, I would expect the EventFilter to be able to handle 
> expirations, invalidations, evictions etc., maybe even reads as well 
> (whether through separate methods or enums).

You can indeed listen for cache entry visited events, at least in local listeners.

> 
> ModificationFilter could be better (in TX I think we use term 
> 'modifications' for all CUD ops), but we have already used 
> CacheEntryModified for 'update'.
> 
> 
>> 
>>>>> Will, what would be the overall impact on the API as right now the KeyValueFilter is reused between several components, like the cluster iterator.
>>>>> 
>>>>> Cheers,
>>>>> --
>>>>> Mircea Markus
>>>>> Infinispan lead (www.infinispan.org)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> 
>>>> --
>>>> Galder Zamarreño
>>>> galder at redhat.com
>>>> twitter.com/galderz
>>>> 
>>>> 
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Galder Zamarreño
>> galder at redhat.com
>> twitter.com/galderz
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz