ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Semyon Boikov <sboi...@gridgain.com>
Subject Re: Issue with near cache update
Date Wed, 25 Mar 2015 06:02:43 GMT
Yes, this is possible, will implement this today.

On Tue, Mar 24, 2015 at 6:38 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> I think we can do better than flushing near cache for every topology
> version change.
>
> Let's say that that topology version in new cache entry is 1 and the actual
> topology version is 4. Then we could check if the entry key changed
> assigned between 1 and 4. For example, if the cache key primary node didn't
> change on version 2, 3, and 4, then there is no point to flush the near
> cache entry.
>
> Would this be possible to implement?
>
> D.
>
> On Tue, Mar 24, 2015 at 8:11 AM, Semyon Boikov <sboikov@gridgain.com>
> wrote:
>
> > Hi,
> >
> > Today I investigated failures in failover suite and found issue with near
> > cache update. Now when near cache entry is initialized we store primary
> > node id, and when value is requested from near cache entry we check that
> > stored node is still primary (NearCacheEntry.valid()).
> > Following scenario is possible (reproduces in our test):
> > - there are two nodes A is primary, B is near
> > - near cache entry is initialized on B, A is stored in near cache entry
> as
> > primary
> > - new node C joins grid and becomes new primary
> > - values is updated from C, it is not aware about near reader B and value
> > in near cache on B is not updated
> > - node C leaves grid, A again becomes primary
> > - value is requested from near cache entry on B, it sees that stored
> node A
> > is still primary and returns outdated value
> >
> > As a simple fix I changed GridNearCacheEntry to store current topology
> > version at the moment when entry was initialized from primary, and method
> > NearCacheEntry.valid() checks that topology version did not change.
> > Assuming topology should not change often this fix should not impact near
> > cache performance.
> >
> > The only case when topology can change often is usage of client nodes.
> When
> > support for client nodes will be fully implemented we will need some way
> to
> > check that cache affinity topology did not change.
> >
> > Thoughts?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message