[
https://issues.jboss.org/browse/ISPN-1466?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on 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.
Async configuration tag affects communication between cache and
HotRod client
-----------------------------------------------------------------------------
Key: ISPN-1466
URL:
https://issues.jboss.org/browse/ISPN-1466
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.0.ALPHA1, 5.1.0.BETA1
Reporter: Martin Gencur
Assignee: Manik Surtani
When using a REPL (replicated) cache with configuration tag <async
useReplQueue="true" replQueueMaxElements="3"
replQueueInterval="1000" />, 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 MaxElements limit or QueueInterval). I'll attach a testcase but
here's a test snippet that fails at first assert:
{code}
@Test
public void testQueueSize() throws Exception {
RemoteCache<String, String> asyncCache1 = rcm1.getCache(asyncCacheSize);
RemoteCache<String, String> asyncCache2 = rcm2.getCache(asyncCacheSize);
asyncCache1.clear();
asyncCache1.put("k1", "v1");
assertTrue(null != asyncCache1.get("k1"));
assertTrue(null == asyncCache2.get("k1"));
asyncCache1.put("k2", "v2");
//k3 fills up the queue -> flush
asyncCache1.put("k3", "v3");
Thread.sleep(1000); //wait for the queue to be flushed
assertTrue(null != asyncCache1.get("k1"));
assertTrue(null != asyncCache2.get("k1"));
}
{code}
IMO when I have cache A and B in a cluster and the cache entry is stored into the cache
A, it should be visible at A and not in B. After flushing the queue it should be visible
also at B.
Here's the test:
https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes...
(to run it, one has to install infinispan-arquillian-container into local maven
repository, and run "mvn clean verify -Dnode0.ispnhome=${server1.home}
-Dnode1.ispnhome=${server2.home}", e.g. mvn clean verify
-Dnode0.ispnhome=/home/mgencur/Java/infinispan/infinispan-5.1.0.BETA1
-Dnode1.ispnhome=/home/mgencur/Java/infinispan/infinispan-5.1.0.BETA1-2
)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira