Listeners data affinity support

[kyoku]

Hello,

i have a question about listeners data affinity, i hope you can help me.

Does Infinispan listeners support data affinity?

I mean, does a listener can be activated only when data are added to the

local cache (local cache-level notification)?

I am now trying to use EventImpl->isOriginLocal in order to guarantee

the the data affinity.

In my scenario the application is deployed to several nodes. A producer

fill the grid and consumers have to process only data belonging to their

node (local data).

Thank you in advance.

- Daniele

[galder.zamarreno]

The listener is activated from the moment you register it. You seem to be using the best option available which is calling isOriginLocal().

[kyoku]

I am sorry,

i did a mistake writing my question.

The right one is: does a listener can be notified only when data are added to the local cache?

Anyway isOriginLocal() works fine, the only bad thing is that all listeners are notified.

Thank you

[galder.zamarreno]

Right, you mean getting notification only when data is added locally as opposed to when data is replicated from a different node? No, that's not possible.

[gdanov]

Hi,

I am not 100% sure I want to achieve the same goal, so let me describe what I need:

• in a distributed (partitioned) cache node A does cache.put(<key>, <value>)
• the <key> is assigned to nodes B & C (when there is redundancy)
• I want the listener on only one of these (B xor C) nodes to process the event

I read the manual, did some experiments and I understand that in Infinispan nodes B & C are equal, there is no such thing as primary node when data is distributed/mutated.

However in your latest 5.1.x CR I read about the single lock owner improvement, so at least for locks now there is such thing as primary node. Would it be good idea to use consistentHash(key).get(0) in the listener and compare it to the local adress in order to decide if the message should be processed? I would expect that such aproach gives me exactly what I need - is my understanding correct?

Cheers,

Georgi

[dan.berindei]

Yes, right now using DistributionManager.locate(key).get(0) is your best option.

However, if the primary owner leaves you don't won't get a notification on the new primary owner for each key, on a DataRehashedEvent you'll have to iterate over all the keys and see which ones you're the new primary owner for. I'm not sure if you need this in your use case, but I thought I should mention it.

[gdanov]

Thank you. I also think about owner change situation.

One thing - while browsing the API I noticed this method:

DistributionManager().getConsistentHash()

                .locate(event.getKey(), 0)

what is the effect of the replCount argument? I assumed if I put zero it would give me the "master" node and empirically looks like I am right. What is the difference related to your suggestion?

Cheers,

Georgi

[dan.berindei]

replCount would be the number of owners you want to find for that key. 0 should be an invalid argument but I guess we don't check it and it works with the current consistent hash implementations.

It can stop working at any moment, so you should use locate(key, 1) instead.