[
https://issues.apache.org/jira/browse/HDDS-1986?focusedWorklogId=325147&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325147
]
ASF GitHub Bot logged work on HDDS-1986:
----------------------------------------
Author: ASF GitHub Bot
Created on: 08/Oct/19 15:52
Start Date: 08/Oct/19 15:52
Worklog Time Spent: 10m
Work Description: bharatviswa504 commented on pull request #1588:
HDDS-1986. Fix listkeys API.
URL: https://github.com/apache/hadoop/pull/1588#discussion_r332593486
##########
File path:
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/OmMetadataManagerImpl.java
##########
@@ -680,26 +688,85 @@ public boolean isBucketEmpty(String volume, String
bucket)
seekPrefix = getBucketKey(volumeName, bucketName + OM_KEY_PREFIX);
}
int currentCount = 0;
- try (TableIterator<String, ? extends KeyValue<String, OmKeyInfo>> keyIter =
- getKeyTable()
- .iterator()) {
- KeyValue<String, OmKeyInfo> kv = keyIter.seek(seekKey);
- while (currentCount < maxKeys && keyIter.hasNext()) {
- kv = keyIter.next();
- // Skip the Start key if needed.
- if (kv != null && skipStartKey && kv.getKey().equals(seekKey)) {
- continue;
+
+
+ TreeMap<String, OmKeyInfo> cacheKeyMap = new TreeMap<>();
+ Set<String> deletedKeySet = new TreeSet<>();
+ Iterator<Map.Entry<CacheKey<String>, CacheValue<OmKeyInfo>>> iterator =
+ keyTable.cacheIterator();
+
+ //TODO: We can avoid this iteration if table cache has stored entries in
+ // treemap. Currently HashMap is used in Cache. HashMap get operation is an
+ // constant time operation, where as for treeMap get is log(n).
+ // So if we move to treemap, the get operation will be affected. As get
+ // is frequent operation on table. So, for now in list we iterate cache map
+ // and construct treeMap which match with keyPrefix and are greater than or
+ // equal to startKey. Later we can revisit this, if list operation
+ // is becoming slow.
+ while (iterator.hasNext()) {
Review comment:
With current new code when the list happens we should consider entries from
buffer and DB. (As we return the response to end-user after adding entries to
cache). So, if user does list as next operation(next to create bucket) the
bucket might/might not be there until double buffer flushes. As until double
buffer flushes, we will have entries in cache. (This will not be problem for
non-HA, as we return the response, only after the flush)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 325147)
Time Spent: 2.5h (was: 2h 20m)
> Fix listkeys API
> ----------------
>
> Key: HDDS-1986
> URL: https://issues.apache.org/jira/browse/HDDS-1986
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Reporter: Bharat Viswanadham
> Assignee: Bharat Viswanadham
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This Jira is to fix listKeys API in HA code path.
> In HA, we have an in-memory cache, where we put the result to in-memory cache
> and return the response, later it will be picked by double buffer thread and
> it will flush to disk. So, now when do listkeys, it should use both in-memory
> cache and rocksdb key table to list keys in a bucket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
