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