Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-237

Cache put on key owner with single owner configuration shouldn't go remote

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Minor Minor
    • 4.0.0.CR1
    • 4.0.0.BETA2
    • Core
    • None

      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'@localhost.localdomain-35146 and the sole recipient of that key is precisely Cache 'dist'@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.

              rh-ee-galder Galder Zamarreño
              rh-ee-galder Galder Zamarreño
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: