[infinispan-dev] Hot Rod Remote Events #3: Customizing events

[Radim Vansa]

On 09/22/2014 07:38 PM, William Burns wrote:
> On Thu, Sep 18, 2014 at 1:37 PM, Radim Vansa <rvansa at redhat.com> wrote:
>> On 09/18/2014 07:21 PM, William Burns wrote:
>>> On Thu, Sep 18, 2014 at 4:11 AM, Galder Zamarreño <galder at redhat.com>
>>> wrote:
>>>> Radim, adding -dev list since others might have the same qs:
>>>>
>>>> @Will, some important information below:
>>>>
>>>> On 18 Sep 2014, at 08:16, Radim Vansa <rvansa at redhat.com> wrote:
>>>>
>>>>> Hi Galder,
>>>>>
>>>>> re: to your last blogpost $SUBJ: I miss two information there:
>>>>>
>>>>> 1) You say that the filter/converter factories are deployed as JAR - do
>>>>> you need to update infinispan modules' dependencies on the server, or can
>>>>> you do that in any other way (via configuration)?
>>>> There’s nothing to be updated. The jars are deployed in the deployments/
>>>> folder or via CLI or whatever other standard deployment method is used. We
>>>> have purpousefully built a deployment processor that processes these jars
>>>> and does all the hard work for the user. For more info, see the
>>>> filter/converter tests in the Infinispan Server integration testsuite.
>>>>
>>>>> This is more general question (I've ran into that with compatibility
>>>>> mode as well), could you provide a link how custom JARs that Infinispan
>>>>> should use are deployed?
>>>> There’s no generic solution at the moment. The current solution is
>>>> limited to filter/converter jars for remote eventing because we depend on
>>>> service definitions in the jar to find the SPIs that we need to plugin to
>>>> the Infinispan Server.
>>>>
>>>>> 2) Let's say that I want to use the converter to produce diffs,
>>>>> therefore the converter needs the previous (overwritten) value as well.
>>>>> Would injecting the cache through CDI work, or is the cache already updated
>>>>> when the converter runs? Can this be reliable at all?
>>> When the notification is raised it has already been committed into the
>>> data container so it is not possible to do a get at this point.
>>>
>>>> Initially when I started working on remote events stuff, I considered the
>>>> need of previous value in both converter and filter interfaces. I think they
>>>> can be useful, but here I’m relying on Will’s core filter/converter
>>>> instances to provide them to the Hot Rod remote events and at the moment
>>>> they don't. @Will, are you considering adding this? Since it affects API, it
>>>> might be a good time to do this now.
>>> I actually was talking to Emmanuel about this yesterday for a bit.  It
>>> seems that we will need to expose the previous value to at least the
>>> KeyValueFilter, but it might be best to also do this for the Converter
>>> as well.  I as thinking of adding another interface that extends the
>>> KeyValueFilter that would be kept in the notification package that
>>> passes both the previous value and the new value (the same could be
>>> done for Converter).  With this change I am also thinking maybe the
>>> addListener methods would take the new interface instead of
>>> KeyValueFilter as well possibly.  What do you guys think?
> Talking with Mircea we are thinking that the least confusing way of
> implementing this is to instead just change the KeyValueFilter and
> Converter interfaces to instead have an additional parameter of
> oldValue passed along in addition to the others.  Unfortunately some
> uses of these interfaces does not fully make sense, especially outside
> of events, but in those cases we will always pass a null oldValue and
> I will update the other methods to reflect this.  Such cases are
> cluster entry iterator and data container iteration.
>
> Any objections or thoughts?

I understand that you don't want zillions of interfaces, but in my 
opinion, the interface should always fit its purpose. I would rather 
have UpdateFilter.accept(key, oldValue, oldMetadata, newValue, 
newMetadata) and similar UpdateConverter than reusing the interface with 
dummy arguments elsewhere.

>
>>
>> Please, consider also the corner cases such as overwriting already updated
>> value, e.g. after OutdatedTopologyException. Sometimes the oldValue might
>> not be correct (we probably can't evade this but I hope we can detect that
>> it might have happened) and the Converter should react to that - e.g. by
>> sending full new value instead of empty diff (because oldValue == newValue).
> Unfortunately it is too late to retrieve the old value by the time we
> do the retry if it was already replicated to a backup owner.  We do
> detect this and provide that info the Listener event, but talking with
> some others I am unsure if providing this information to the
> Filter/Converter is fully needed.

Not providing that info to Converter limits the use-case of converter 
producing deltas. In fact it's even worse - users will write that 
converter (because the won't expect incorrect old values - nobody reads 
documentation) and it will give them unreliable results.

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA