Re: [infinispan-dev] Clustered Listener
Hello,
Are you talking about non clustered listeners? It seems unlikely you
would need so many cluster listeners. Cluster listeners should allow
you to only install a small amount of them, usually you would have
only additional ones if you have a Filter applied limiting what
key/values are returned.
Our usage of the clustered API is a corner case, but the
installation of
a listener for a specific key (or key range) could be of general
purpose. My point was that installing all filters everywhere is costly
as every node should iterate over all filters for every modification.
Our tentative code for key-specific filtering is available at
github.com/otrack/Leads-infinispan
(org.infinispan.notifications.KeySpecificListener and
org.infinispan.notifications.cachelistener.CacheNotifierImpl).
Is the KeyFilter or KeyValueFilter not sufficient for this? void
addListener(Object listener, KeyFilter<? super K> filter); <C> void
addListener(Object listener, KeyValueFilter<? super K, ? super V>
filter, Converter<? super K, ? super V, C> converter); Also to note if
you are doing any kind of translation of the value to another value it
is recommended to do that via the supplied Converter. This can give
good performance as the conversion is done on the target node and not
all in 1 node and also you can reduce the payload if the resultant
value has a serialized form that is smaller than the original value.
Indeed, this
mechanism suffices for many purposes, I was just pointing
out that it might be sometimes expensive.
> In such a case, the listener is solely
> installed at the key owners. This greatly helps the scalability of the
> mechanism at the cost of fault-tolerance since, in the current state of
> the implementation, listeners are not forwarded to new data owners.
> Since as a next step [1] it is planned to handle topology change, do you
> plan also to support key (or key range) specific listener ?
These should be covered with the 2 overloads as I mentioned above.
This should be the most performant way as the filter is replicated to
the node upon installation so a 1 time cost. But if a key/value pair
doesn't pass the filter the event is not sent to the node where the
listener is installed.
I agree.
> Besides,
> regarding this last point and the current state of the implementation, I
> would have like to know what is the purpose of the re-installation of
> the cluster listener in case of a view change in the addedListener()
> method of the CacheNotifierImpl class.
This isn't a re-installation. This is used to propgate the
RemoteClusterListener to the other nodes, so that when a new event is
generated it can see that and subsequently send it back to the node
where the listener is installed. There is also a second check in
there in case if a new node joins in the middle.
The term re-installation was
inappropriate. I was meaning here that in
my understanding of the code of CacheNotifierImpl, a second check seems
of no need since if a new node joins the cluster afterward it still has
to install the pair <filter,converter>.
Best,
Pierre
ps: sorry for the late answer.