Single hosted entry not working

[yairogen]

I am using infinispan version 7.0.3.

My requirement is as follows:

1. use embedded cache

2. allow active/active application servers.

3. if a key is added in server A, server B should be able to retrieve once it sees it doesn't exist locally.

4. Server should not sync caches by replication (mainly for performance and traffic reasons).

5. Cluster should not use UDP broadcast

Judging from infinispan documentation this should work if I set owners = 1.

My tests uses 2 rest servers (2 identical instances of the same app). I first call server B to create the resource which puts the resource into the cache. I stop Server B. I then call Server A with a get with resource ID. I expect it to fail on not finding the cache entry - but it does find it.

Probably some sort of replication is taking place although I don't want it.

Code I'm using is:

GlobalConfiguration globalConfig =  new GlobalConfigurationBuilder().transport().defaultTransport().clusterName("my-cluster").addProperty("configurationFile", "jgroups-tcp.xml");
DefaultCacheManager manager = new DefaultCacheManager(globalConfig);
Configuration config = new ConfigurationBuilder().read(manager.getDefaultCacheConfiguration).clustering().cacheMode(CacheMode.DIST_SYNC).l1().lifespan(sessionExpiration).hash().numOwners(1).build();
manager.defineConfiguration("myCache", config);
Cache<String, MySession> cache = manager.getCache("myCache");

Working with the cache is the regular API's: put, get, containsKey and also the values() method.

The jgroups file is attached.

What am I missing?

[nadirx]

You're missing the fact that entries are not stored on the node where the put operation is performed, but on the node determined by the consistent hash algorithm. Therefore, when you put something from server B it probably got stored on server A, and that's why both nodes find it, and node A keeps seeing it even when node B leaves the cluster. If you need to keep data local to the node, use the KeyAffinityService.

[yairogen]

Thanks Tristan.

This is interesting. I think that the KeyAffinityService is an overkill for me. I need the key to the resource id.

If you think my usage in code and the attached jgroup file support my requirements (i.e. no replication will be done - only one node any given key) then I'm good.

If the above is correct, if I would have set many keys on Node B, I can expect that some of them will be missing on Node A assuming after putting them I take down server B?