On 11/19/2013 09:48 AM, Emmanuel Bernard wrote: > Hey there, > > Here are a few comments based on a quick reading. > I might have totally misread or misinterpreted what was exposed, feel > free to correct me. > > ## General > > I think you are restricting the design to listeners: > > * that only listen to raw entry changes > * whose processing is remote > * with no way to filter out the event from the server > > Is that correct? I can see that it does address the remote L1 use case > but I feel like it will close the doors to many more use cases. An > interesting example being continuous query. Please, use the term "near cache" rather than "remote L1". L1 is rather ambiguous as it already represents L1 cache and L1 HotRod intelligence level.
> > In that use case the listener code runs a filtering logic server side > and only send keys that are impacted by the query plus some flag > defining whether it's added to changed or removed from the corpus. > The key is filtering event before sending it to the client. > > I wish the design document was showing how we can achieve a general > purpose remote listener approach but have a step 1 that is only > targeting a restricted set of listeners if you feel that it's too much > to chew. I don't want us to be trapped in a situation where backward > compatibility prevent us from adding use cases. I was also suggesting that listener on particular key should be mandatory requirement. However, any general server-side filtering logic would be hard to specify as HotRod is language-unaware binary protocol. Therefore, the best you could get is some kind of binary regular expressions. For the start, global/one-key filtering is a good start and the door are not closed for any further options. > > ## Specific questions > > When the topology changes, it is the responsibility of the client to add > the listener to the new servers that show up. Correct? The API is a > global addRemoteListener but I imagine the client implementation will > have to transparently deal with that. > I wonder if a server approach is not more convinient. At least it does > not put the burden and bugs in several implementations and several > languages. +1 > > You never send code at the moment. Only one kind of listener is > available and listeners to all entry change and deletion. Correct? > > Why not have the ability to listen to new entry events? That would limit > generic listeners as it is. > > Do you have plans to make the ACK optional depending on the listener > requirement? Looks like an expensive process. > > "Only the latest event is tracked for ACK for a given key" > It seems it's fine for L1 but would be a problem for many more generic > listeners. > > Emmanuel Radim > > On Tue 2013-11-12 16:17, Galder Zamarreño wrote: >> Hi all, >> >> Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events >> >> I've just finished writing up the Hot Rod remote events design document. >> Amongst many other use cases, this will enable near caching use cases with >> the help of Hot Rod client callbacks. >> >> Cheers, >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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
