[
https://issues.apache.org/jira/browse/IGNITE-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-9315:
---------------------------------------
Description:
There are cases when eviction metadata from near cache's eviction policy may be
added to a DHT cache entry, leading to unpredictable behavior.
The bug is caused by coding mistakes when a DHT entry is being updated, but
near cache entry is being touched.
E.g. in GridDhtPartitionDemander::preloadEntry:
{code}
GridCacheContext cctx = grp.sharedGroup() ? ctx.cacheContext(entry.cacheId()) :
grp.singleCacheContext();
cached = cctx.dhtCache().entryEx(entry.key());
// cctx = cached.context();
if (log.isDebugEnabled())
log.debug("Rebalancing key [key=" + entry.key() + ", part=" + p + ", node="
+ from.id() + ']');
if (preloadPred == null || preloadPred.apply(entry)) {
if (cached.initialValue(
entry.value(),
entry.version(),
entry.ttl(),
entry.expireTime(),
true,
topVer,
cctx.isDrEnabled() ? DR_PRELOAD : DR_NONE,
false
)) {
cctx.evicts().touch(cached, topVer); // Start tracking.
{code}
Here `cached` is always DHT entry, but `cctx` can be near.
There is a similar bug in
GridCacheUtils.createBackupPostProcessingClosure.BackupPostProcessingClosure.
was:
There are cases when eviction metadata from near cache's eviction policy may be
added to a DHT cache entry, leading to unpredictable behavior.
The bug is caused by coding mistakes when a DHT entry is being updated, but
near cache entry is being touched.
E.g. in GridDhtPartitionDemander::preloadEntry:
{code}
GridCacheContext cctx = grp.sharedGroup() ? ctx.cacheContext(entry.cacheId()) :
grp.singleCacheContext();
cached = cctx.dhtCache().entryEx(entry.key());
// cctx = cached.context();
if (log.isDebugEnabled())
log.debug("Rebalancing key [key=" + entry.key() + ", part=" + p + ", node="
+ from.id() + ']');
if (preloadPred == null || preloadPred.apply(entry)) {
if (cached.initialValue(
entry.value(),
entry.version(),
entry.ttl(),
entry.expireTime(),
true,
topVer,
cctx.isDrEnabled() ? DR_PRELOAD : DR_NONE,
false
)) {
cctx.evicts().touch(cached, topVer); // Start tracking.
{code}
Here `cached` is always DHT entry, but `cctx` can be near.
> Eviction meta from near cache may appear in DHT entries
> -------------------------------------------------------
>
> Key: IGNITE-9315
> URL: https://issues.apache.org/jira/browse/IGNITE-9315
> Project: Ignite
> Issue Type: Bug
> Reporter: Stanislav Lukyanov
> Assignee: Stanislav Lukyanov
> Priority: Major
>
> There are cases when eviction metadata from near cache's eviction policy may
> be added to a DHT cache entry, leading to unpredictable behavior.
> The bug is caused by coding mistakes when a DHT entry is being updated, but
> near cache entry is being touched.
> E.g. in GridDhtPartitionDemander::preloadEntry:
> {code}
> GridCacheContext cctx = grp.sharedGroup() ? ctx.cacheContext(entry.cacheId())
> : grp.singleCacheContext();
> cached = cctx.dhtCache().entryEx(entry.key());
> // cctx = cached.context();
> if (log.isDebugEnabled())
> log.debug("Rebalancing key [key=" + entry.key() + ", part=" + p + ",
> node=" + from.id() + ']');
> if (preloadPred == null || preloadPred.apply(entry)) {
> if (cached.initialValue(
> entry.value(),
> entry.version(),
> entry.ttl(),
> entry.expireTime(),
> true,
> topVer,
> cctx.isDrEnabled() ? DR_PRELOAD : DR_NONE,
> false
> )) {
> cctx.evicts().touch(cached, topVer); // Start tracking.
> {code}
> Here `cached` is always DHT entry, but `cctx` can be near.
> There is a similar bug in
> GridCacheUtils.createBackupPostProcessingClosure.BackupPostProcessingClosure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
