[HDDS-6357] RenameKey request has memory leak

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.3.0
• Labels: pull-request-available
• Assignee: Xu Shao Hong
• Reporter: Xu Shao Hong
• Created: 21/Feb/22 09:50
• Updated: 06/Feb/23 07:02
• Resolved: 09/Mar/22 04:49

Description

Issue: The heap is full of keyInfo from TableCache after renameKey API test and the memory can not be evicted with manual FGC.

 

During validateAndUpdateCache in OMKeyRenameRequest, the keyTable will add twice cache entry( fromKey and toKey). This process actually does this way:

public void put(CACHEKEY cacheKey, CACHEVALUE value) {
  cache.put(cacheKey, value);
  epochEntries.add(new EpochEntry<>(value.getEpoch(), cacheKey));
}

this EpochEntry right now only supports the unary operation. 

@Override
public int compareTo(Object o) {
  if(this.epoch == ((EpochEntry<?>)o).epoch) {
    return 0;
  } else if (this.epoch < ((EpochEntry<?>)o).epoch) {
    return -1;
  } else {
    return 1;
  }
} 

hence, when renaming A to B in one transaction, the cache will add two cache entries but epochEntries cannot add B after adding A as they are compared as the same.

keyTable.addCacheEntry(new CacheKey<>(fromKey),
    new CacheValue<>(Optional.absent(), trxnLogIndex));

keyTable.addCacheEntry(new CacheKey<>(toKey),
    new CacheValue<>(Optional.of(fromKeyValue), trxnLogIndex)); 

The solution is easy and should be no side effects. 

We can simply add a check for EpochEntry's value.

Issue Links

• is related to: HDDS-6369 PARTIAL_RENAME does not update OM DB
• links to: GitHub Pull Request #3121