Description of problem: This BZ duplicates ISPN-1466. When using a replicated cache with async replication, HotRod client cannot see a cache entry which was just stored into a cache. The entry is visible not before the replication queue is flushed (either because of queue-size or queue-flush-interval). The test is located at https://svn.devel.redhat.com/repos/jboss-qa/edg/edg-functional-tests/trunk/xml-configuration/clustered-cache/src/test/java/org/jboss/test/datagrid/configuration/ClusteredCacheConfigurationTest.java testQueueSize and testQueueFlushInterval methods fail at their first assert.
I'm closing this because the test is not correct. It uses HotRod client in conjunction with REPL mode which does not make sense IMHO. queue-size and queue-flush-interval seem to work fine when using memcached client.
Martin Gencur <mgencur> updated the status of jira ISPN-1466 to Closed
Martin Gencur <mgencur> made a comment on jira ISPN-1466 See the explanation in RH Bugzilla integration comment.
Martin Gencur <mgencur> made a comment on jira ISPN-1466 The test was indeed incorrect but using HotRod client in conjunction with REPL mode makes sense. The requests are then dispatched to the servers in a round-robin manner. (as described here: https://docs.jboss.org/author/display/ISPN/Java+Hot+Rod+client - Request Balancing).
Manik Surtani <manik.surtani> updated the status of jira ISPN-1466 to Reopened
Manik Surtani <manik.surtani> updated the status of jira ISPN-1466 to Resolved
Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-1466 @Martin, for async caches, it might make sense to have a first available, or sticky, load balance policy because round-robin could throw funny results. Isn't that what you meant?
Martin Gencur <mgencur> made a comment on jira ISPN-1466 No... as I now know that the round-robin is used by default when using HotRod client and REPL mode, the failure I got was making sense. I was storing a key/value via HotRod and subsequently did this assert: assertTrue(null != asyncCache1.get("k1")), but since it was configured for ASYNC and used round-robin, the assertion actually tried to find a key in another node than where I stored the key (and the replication did not take place yet) so I got null value. And this is expected IMO.
Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-1466 @Martin, sure it's expected but it's rather confusing for the user. If the cache is configured with ASYNC (repl or dist), it should use a sticky node like load balance policy, where all requests for the same key get directed to the same node. The problem is that the client is not aware of the cache configuration, but it'd be nice in the future for the server to be able to provide hints to the client. In the absence of these hints, if the client developer knows that it's gonna talk to an async cache, it should be able to configure the load balance policy to be sticky-per-key in order to avoid the issue you had. I'm not aware of such LBP for REPl (dist does it by default, I think, by always going to the 1st owner of the key) so maybe we should implement it. Also, not sure if LBP can be configured on a per cache basis either.
Martin Gencur <mgencur> made a comment on jira ISPN-1466 Yes, it would be nice to have something like the sticky-per-key policy for ASYNC caches in REPL mode.
Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-1466 Martin, I've created ISPN-1916.