R and T are too close in my keyboard, obviously I meant: Design of remote… :)
On Feb 20, 2012, at 3:29 PM, Galder Zamarreño wrote: > Hi all, > > Re: https://community.jboss.org/docs/DOC-17571 > > Over the past week and a bit I've been working on a rough prototype for > remote event handling in Hot Rod that covers the server side (I've not done > any work on the Hot Rod client).In the link above you can find my design > notes. > > I wanted to get some feedback on the minimum requirements explained and I > wanted to discuss the need of the optional requirements, in particular the > 1st of the optional requirements. > > The idea is that at a logical level, it'd be interesting to know what the > origin of a modification for a couple of reasons: > > - It allows clients be able to know whether the modification is originated > locally from a logical point of view. If it sounds to abstract, think about > near caches (see preso in > https://www.jboss.org/dms/judcon/presentations/London2011/day1track2session2.pdf) > and imagine a local cache (near cache) configured with a remote cache store > (a Java hot rod client with N channels open at the same time). Remote > listeners could decide to act differently if the modification was originated > locally or not, i.e. if it's not local then remove the key from cache, if > local, it means the modification comes from this remote cache store and so I > have the latest data in memory. This is a very nice optimisation for at least > this use case. > > - This can be extended further. If all channels opened with can be associated > with a logical origin, we could optimise sending back events. For example, > imagine a remote cache store (it has 1 remote cache manager) that has N > channels open with the server. There's no need for all N channels to receive > a notification for a cache removal. As long as one of the channels gets it > event, it's good enough to act to on the local cache. > > As you can see, what I'm heading towards is that for each remote cache > manager started to be id'd uniquely, and this id to be shipped with all Hot > Rod operations. It could be possible to limit the operations that carry such > an id, but this could complicate the protocol. > > Thoughts? > > Also, any thoughts on the need for the 4th optional requirement? For near > caches, remote events are important, but you could limit the need for it with > an aggressive eviction policy in the near cache to cover against lost events. > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
