On Dec 19, 2013, at 1:15 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
>> == 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.
I don't think you are correct.
This is not remote execution in the sense of arbitrary code driven by
the client. Remote execution will likely be triggered, render a
result and stop. It will not send matching events in a continuous fashion.
Plus remote execution will likely involve dynamic languages and I'm not
sure we want to go that route for things like continuous query.
Well, it's remote execution of a condition, which is a type of code :)
From Hot Rod perspective, until remote code execution is in place, we
could add a list of N byte[] that are treated as parameters for the filter, and the filter
deciphers what those mean. So, in your case, there would be only 1 parameter, a byte[],
and it would be unmarshalled by the filter into "where age > 19". If multiple
clients add the same parameter, we could use the same filter instance, that's assuming
equality can be calculated based on the contents of the byte[] by Hot Rod.
WRT your suggestion to activate/deactivate the continous query on the fly, can't we
achieve that with registration/deregistration of listeners? Or are you trying to avoid all
the set up involved in sending the listener registration stuff around? Adding
activate/deactivate would require two new operations.
Cheers,
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org