[
https://issues.apache.org/jira/browse/HDDS-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Attila Doroszlai resolved HDDS-6357.
------------------------------------
Fix Version/s: 1.3.0
Resolution: Fixed
> RenameKey request has memory leak
> ---------------------------------
>
> Key: HDDS-6357
> URL: https://issues.apache.org/jira/browse/HDDS-6357
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Xu Shao Hong
> Assignee: Xu Shao Hong
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> 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:
> {code:java}
> public void put(CACHEKEY cacheKey, CACHEVALUE value) {
> cache.put(cacheKey, value);
> epochEntries.add(new EpochEntry<>(value.getEpoch(), cacheKey));
> }
> {code}
> this EpochEntry right now only supports the unary operation.
> {code:java}
> @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;
> }
> } {code}
> 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.
> {code:java}
> keyTable.addCacheEntry(new CacheKey<>(fromKey),
> new CacheValue<>(Optional.absent(), trxnLogIndex));
> keyTable.addCacheEntry(new CacheKey<>(toKey),
> new CacheValue<>(Optional.of(fromKeyValue), trxnLogIndex)); {code}
> The solution is easy and should be no side effects.
> We can simply add a check for EpochEntry's value.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
