0

I am new to Infinispan. Even after going through Infinispan User Guide & googling through, I am not able to figure out behavior of Infinispan in below cases :

1) Does it lock on HotRod Client reading when rebalancing is taking place ?

2) How does Infinispan behaves with REPL mode with async & nearCache at HotRod client end ? (I found that if nearCache is disabled then it can get the data, but not with nearCache. Does it have to anything with nearCache update?)

Server Code :

GlobalConfigurationBuilder globalConfig = GlobalConfigurationBuilder.defaultClusteredBuilder();
globalConfig.transport().clusterName("infiniReplicatedCluster").globalJmxStatistics().enable().allowDuplicateDomains(Boolean.TRUE);
ConfigurationBuilder configBuilder = new ConfigurationBuilder();
EmbeddedCacheManager embeddedCacheManager = new DefaultCacheManager(globalConfig.build());

configBuilder.dataContainer().compatibility().enable().clustering().cacheMode(CacheMode.REPL_ASYNC)
    .async().replQueueInterval(120, TimeUnit.SECONDS).useReplQueue(true).hash();
embeddedCacheManager.defineConfiguration("TestCache", configBuilder.build());

Cache<String, TopologyData> cache = embeddedCacheManager.getCache("TestCache");
cache.put("00000", new TopologyData());

HotRodServerConfiguration build = new HotRodServerConfigurationBuilder().build();
HotRodServer server = new HotRodServer();
server.start(build, embeddedCacheManager);

Client Code :

ConfigurationBuilder remoteBuilder = new ConfigurationBuilder();
remoteBuilder.nearCache().mode(NearCacheMode.EAGER).maxEntries(100);
RemoteCacheManager remoteCacheManager = new RemoteCacheManager(remoteBuilder.build());
remoteCache = remoteCacheManager.getCache("TestCache");
System.out.println(remoteCache.get(fetchKey));

With above code, scenarios & results are listed below(all the run were done multiple times, resulting in same result) :

-Without nearCache 1 Key --> got value as expected

-With nearCache (LAZY/EAGER) 1 key --> null

-In same run, same Key two times With nearCache (LAZY/EAGER) --> null(first time) - expected value(next time)

Clarification needed : If a sample code to re-verify HotRod client's load balancing(RoundRobin) behavior in DIST mode. (I am successfully able to check it with REPL mode, & it works as it claims)

J. P
  • 356
  • 4
  • 20
  • Judging from the configuration, seems like you're using an older Infinispan version, since we've removed replication queue in newer Infinispan versions. You simply set the cache to be async replicated and that's it. If I were you, I'd see if the issue is present with latest Infinispan stable release, which is 9.1.2 – Galder Zamarreño Nov 14 '17 at 09:16

1 Answers1

1
  1. State transfer in Infinispan is non-blocking
  2. Not sure I understand completely: you mean to say that, when enabling near caching on a Hot Rod client, reading from an async REPL cache doesn't work ? Does it just hang ? Do you have code that you can share ?

A clarification: Hot Rod goes to the primary owner both in DIST and REPL mode (REPL is simply a special DIST mode where number of owners is equal to the size of the cluster) hashed according to the key and will only use Round Robin if the primary is not responding.

Tristan Tarrant
  • 1,299
  • 6
  • 6
  • It means it is not 100% round robin. First the primary node will try to return the value. If in case it fails, then only round robin applies. Is my understanding correct ? If yes, then anytime, for a particular key, primary owner of that key serves all the request rather. – J. P Nov 08 '17 at 14:06
  • & can you please explain the case where Primary Owner is alive but fails to respond (& HotRod client has to go to get the key from other node available) ? – J. P Nov 08 '17 at 14:09
  • Yes, your understanding is correct. As for the second q, It might fail to respond for various reasons on the network between client and server; the inter-node communication may use different switch. Also the node might be overloaded or doing GC and client times out (if its timeout is set lower). It's network, weird things can happen. – Radim Vansa Nov 10 '17 at 02:12
  • @RadimVansa : & how should ASYN behavior in the cases mentioned above? & if this is expected behavior then why it gives 'null' in 1st attempt with nearCache ? – J. P Nov 13 '17 at 07:31
  • @J.P Even when the cache is ASYNC, the reads (get()) are synchronous. Feel free to file a JIRA and add test case reproducing this. – Radim Vansa Nov 16 '17 at 12:30
  • @RadimVansa : In your second last comment, which timeout property you talk about when you say '(if its timeout is set lower)' ? Can you throw some light over it ? – J. P Dec 01 '17 at 06:27
  • When reading a response the maximum blocking time is determined by `Configuration.socketTimeout()`. After that the operation is retried on another node, and there you wait at most socketTimeout, too. – Radim Vansa Dec 01 '17 at 08:07