On 09/22/2014 07:38 PM, William Burns wrote: > On Thu, Sep 18, 2014 at 1:37 PM, Radim Vansa <rva...@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 <gal...@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 <rva...@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 <rva...@redhat.com> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
