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

[William Burns]

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?

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

>
> Radim
>
>
>>> In terms of how to workaround it, a relatively heavy weight solution
>>> would be for the converter to track key/values as it gets events and them
>>> compare event contents with its cache. Values should be refs, so should not
>>> take too much space… I doubt injecting a CDI cache would work.
>>>
>>> Cheers,
>>>
>>>> Thanks
>>>>
>>>> Radim
>>>>
>>>> --
>>>> Radim Vansa <rvansa at redhat.com>
>>>> JBoss DataGrid QA
>>>>
>>>
>>> --
>>> 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
>