Guys, I'd like to resurrect this discussion as it seems to me that I found more serious issue here. Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-4465. Can someone take a look at it?
Basically, it looks like under some circumstances we can get a cache miss after the value was already loaded from store. The behavior is very weird, so the description is a bit vague. However, I managed to create a small test that shows the problem (attached to the ticket). -Val On Thu, Oct 6, 2016 at 2:10 AM, Yakov Zhdanov <yzhda...@apache.org> wrote: > I don't think there is a way to fix this other than having some bounded > collection of futures finished with "null" result. > > --Yakov > > 2016-10-04 23:09 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Hm... sounds like a bug. > > > > On Tue, Oct 4, 2016 at 1:06 PM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Folks, > > > > > > I noticed strange behavior when read-through done from several > concurrent > > > threads. Basically, if miss happened in two thread, they can both load > > the > > > value from store. We have CacheStoreBalancingWrapper which I believe is > > > supposed to solve this, but there is still a race, because the loading > > can > > > start after the future in the wrapper is already completed and > removed. I > > > think it can potentially be a performance issue in case the loading > > process > > > takes significant amount of time. > > > > > > Is this by design and is there any way to make it more reliable? Why > > don't > > > we load within the entry sync block, like we do with updates? > > > > > > -Val > > > > > >