Hello!
Yes, using other continuous query to watch changes of this set looks OK. Of
course there will be some yak shaving to do.
Regards,
--
Ilya Kasnacheev
вт, 26 мая 2020 г. в 12:28, zork :
> Thanks.
> So I can think of two ways using which such a set could be maintained by
> the
> remote
Thanks.
So I can think of two ways using which such a set could be maintained by the
remote node:
1. The remote node listens to a new topic through which the local node sends
it a message whenever the set changes.
2. Or, the local node puts the set values in a new table in the cache itself
and
Hello!
No, updating local set will not be sent over to the remote node, but on the
remote node you can probably update it from your filter:
qry.setRemoteFilterFactory(new Factory>() {
@Override public CacheEntryEventFilter
create() {
return new
Hi,
Sorry but I could not get it to work.
The standard way of defining a remote filter as shown in sample repo is
something like:
qry.setRemoteFilterFactory(new Factory>() {
@Override public CacheEntryEventFilter
create() {
return new
Hello!
Remote filter is code. It can execute arbitrary logic. It can adjust to
what it needs to filter, change its own behavior with time.
Regards,
--
Ilya Kasnacheev
пн, 18 мая 2020 г. в 15:40, zork :
> Hi Ilya,
> Thanks for your response.
> I'm aware of remote filters but can these filters
Hi Ilya,
Thanks for your response.
I'm aware of remote filters but can these filters be modified once the query
is already attached?
Because if not, then this would not solve my use case as the filter would
always give me updates on a fixed subset of keys, however in my case this
subset is varying
Hello!
Continuous query has a notion of 'remote filter'. This is a piece of code
which is executed near data (on server nodes) to determine if the update
needs to be sent over network.
https://apacheignite.readme.io/docs/continuous-queries#remote-filter
If you define a proper remote filter,
Hi,
We have a table in ignite cache which would have say around 1Mn entries at
anytime. Now we wish to listen on updates on a subset of these keys (say
5-10 thousand keys) and this subset keeps on changing as the user
subscribes/unsubscribes to these keys.
The way it is currently working is one
