4 Replies Latest reply on Sep 11, 2014 8:12 AM by Radim Vansa

    Existing cache entry not found (distributed cache, async store, IGNORE_RETURN_VALUES)

    Alfie Kirkpatrick Newbie

      We are using 6.0.0-Final. We have a 3 node cluster, using a distributed cache (1 owner) and a custom mongodb store which operates async on writes using a basic LinkedBlockingQueue. We stopped using


      Occasionally (about 0.02% of the time) in tests we are seeing a get for a previously put key return null.


      Our test harness is multi-threaded but it cannot do a get for a key before the put has completed, and the key (a session id) has been returned. So there's no chance the get is happening before the put returns. We should never see a cache miss.


      I'm trying to understand if the following assumptions are correct...

      - Gets for a key will always be retrieved from the owner node for that key (assuming the node is up)

      - The owner node will always serve from memory assuming the cache size doesn't exceed max entries (ie. the entry has not been evicted)


      If these are right, it's hard to understand the behaviour we're seeing!


      I have just noticed at least one occurrence of this problem where the put and the get are on the same node, which is very strange to me.


      Note that we also use IGNORE_RETURN_VALUES on cache puts, because we're not interested in the previous session state. In my tests, it *seems* as though using this flag aggrevates this problem. I've run several tests without this flag and don't see the issue at all. Can anyone explain why this might be? Using this flag significantly improves performance for us.


      As usual any advice and guidance much appreciated.