[infinispan-issues] [JBoss JIRA] Created: (ISPN-237) Cache put on key owner with single owner configuration shouldn't go remote

Cache put on key owner with single owner configuration shouldn't go remote -------------------------------------------------------------------------- Key: ISPN-237 URL: https://jira.jboss.org/jira/browse/ISPN-237 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.0.0.BETA2 Reporter: Galder Zamarreno Assignee: Manik Surtani Priority: Minor Fix For: 4.0.0.CR1 A very simple test that can be created for ISPN-234 without having to wonder what the Rehash thread is doing, is to simply create a cluster of 2 in dist mode and give number of owners 1. Then, take a key, find out the owner and do a put on that owner. Assuming that such operation did not go remote, you could then replicate ISPN-234 easily by doing a get() on the other cache which is a non-owner. This would force the non-serializable data to be brought from the owner cache and this would fail in the same way as ISPN-234. Now, the cache put on the single owner for that key shouldn't go remote but it does. So, let's say let's say that you call a put on Cache 'dist'(a)localhost.localdomain-35146 and the sole recipient of that key is precisely Cache 'dist'(a)localhost.localdomain-35146. Well, DistributionInterceptor is still trying to go remote for this (is executing rpcManager.invokeRemotely(rec, command, sync);) when surely it shouldn't do, correct? I know it's an edge case (who would use single owner?) but it'd make my life easier to test 234 if we added that optimization. So, if single key recipient and address is same as of the one from the recipient, don't do anything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira