[infinispan-dev] Clustered Listener

[Pierre Sutra]

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.