[infinispan-dev] Design of Remote Hot Rod events - round 2

Emmanuel Bernard emmanuel at hibernate.org
Fri Dec 13 11:08:05 EST 2013


Much better. Some more feedback.

== Filter and converter

I am wondering if there is a benefit in separating filters and
converters. It does add some understanding complexity so a single
ServerListener with the methods from RemoteFilter / RemoveConverter
might be better.

Should filter / converter impls have a @FilterId() / @ConverterId or
should even the id be configured as late binding?

== Custom event contents

I an not following, is the custom content always received as byte[] by
the client?  Or is the generic parameter K in
RemoteCacheEntryCustomEvent<K> the actual return type of getEventData() ?

I'd love (in Java) to declare the returned type of the converter via
generics in the RemoteConverter impl (class SomeRC<String> extends
RemoteConverter<String> {}) and somehow use that information on
the client side.

== Example of continuous query atop remote listeners

Thinking about how to implement continuous query atop this
infrastructure I am missing a few things.

The primary problem is that I don't want to enlist a filter id per
continuous query I want to run. Not only that but I'd love to be able to
add a continuous query on the fly and disable it on the fly as well per
client. For that filters and converters are not flexible enough.

What is missing is the ability to pass parameters from the client to
the remote filter and remote converter. Parameters should be provided
*per client*. Say Client 1 register the continuous query listener with
"where age > 19" and client 2 registers the CQ listener with "where name
= emmanuel". The filter knowing for which client it filters, it will be able to only
return the keys that match the query.

Another useful but not fundamental notion is the ability for a client to
enlist the same filter id / converter id tuple with different
parameters. The same client might be interested in several different
queries.

BTW have you considered some kind of multiplexing mechanism in case the
several client listeners on the same client are interested in the same
event?

Emmanuel

On Thu 2013-12-05 17:16, Galder Zamarreño wrote:
> Hi all,
> 
> Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
> 
> Thanks a lot for the feedback provided in last thread. It was very constructive feedback :)
> 
> I've just finished updating the design document with the feedback provided in the previous email thread. Can you please have another read and let the list know what you think of it?
> 
> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
> 
> Cheers,
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
> 
> Project Lead, Escalante
> http://escalante.io
> 
> Engineer, Infinispan
> http://infinispan.org
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


More information about the infinispan-dev mailing list