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

[Radim Vansa]

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?

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

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