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

[Galder Zamarreño]

On Dec 13, 2013, at 5:08 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> 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.

I think the two are fairly tight in, so I think that might be a good idea.

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

That falls into the configuration part which I hoped @Tristan would provide some insight on how we'd plug these filter/convert impls into the server. If they're defined via Infinispan configuration, the ID could be provided via there. If they're found via service loader pattern, annotations could be used, or callback methods. The former is probably more elegant.

> == 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.

Event data is a byte[] as formatted by the converter on the server side. On the client side, I can only expose this as is, as byte[]. The callback would then need to disect it somehow.

The K in RemoteCacheEntryCustomEvent<K> should be removed really, since with these custom event calls, there's no key provided.

> == 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.

This all sounds a bit like remote code exectution to me? You're asking for the client to pass some kind of executable thing that acts as a filter. That's a separate feature IMO, which I believe @Tristan is looking into. Once that's in place, I'm happy to enhance stuff in the remote event side to support it.

>From a remote event support perspective, server side static filter/converters is as far as I'd like to take it.

> 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?

If they're in the same client, they'd have the same source ID, so just sending it once would be doable, assuming they're not using different converters.

Cheers,

> 
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org