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 <
[hidden email]> 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 <
[hidden email]>:
>
> > Hm... sounds like a bug.
> >
> > On Tue, Oct 4, 2016 at 1:06 PM, Valentin Kulichenko <
> >
[hidden email]> 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
> > >
> >
>
Locked
