[infinispan-dev] Design of Remote Hot Rod events

[Emmanuel Bernard]

Cool, I was afraid you had sent my feedback to /dev/null :)

On Wed 2013-11-27  8:35, Galder Zamarreño wrote:
> > 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 like this idea. It'd easier to manage this filtering on the server side than on the client side, plus it would reduce traffic by making the filtering happen before it's left the server. Assuming that filtering is done per-cache, the user would add a remote listener for a cache, and the filtering of which keys to notify clients on would be defined server side. The main capability you lose by doing this is the ability for different clients to filter differently keys on the same cache, but I'm not sure how common that'd be.

Actually, a client could "manually" do client side filtering if it
pleases him or if it makes more sense. From the server PoV you would
simply return all events to that client because the client would have
activated the "all your base are belong to us" listener.

> > You never send code at the moment. Only one kind of listener is
> > available and listeners to all entry change and deletion. Correct?
> 
> Hmmm, not really. You shoud be able to add as many listeners as you want per cache.
> 

Yes but in your approach there are client side listeners so the listener code is
not shipped to the server.
In a subsequent discussion on this thread, I proposed the idea of named
listeners whose code is already pre deployed on the server.
Plus we can imagine using the scripting integration engine in the JVM to
run code that does not require a compilation phase.

> > Why not have the ability to listen to new entry events? That would limit
> > generic listeners as it is.
> 
> This could be part of the filtering logic somehow. I mean, there's two types of filtering:
> 
> 1. Filtering by type of operation: create, update, remove
> 2. Filter by key
> 
> Filtering by key can possibly done on the server side as you suggest. What about filtering by type of operation? Doing it server side again would hugely reduce traffic.

To me all can be done on the server. And as I said earlier, we could
have a default listener that listens to everything and send all events
to the client. In that case the client is responsible for discarding
events as it pleases. Basically your use case will be covered by the
server side approach AFAIU.

Anyways back to the 3000 meters view, if you go for the server side
approach, I think we will ahve a much more powerful and efficient
solution esp since we can emulate the client side approach with it.

Emmanuel