[
https://issues.apache.org/jira/browse/HDDS-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng resolved HDDS-6274.
------------------------------
Resolution: Won't Fix
After some discussion, we decided not to iterate cache of {{TenantStateTable}}
in {{OzoneManager#listTenant}}. We previously decided to use VOLUME_LOCK to
protect tenant table access (HDDS-6063). With this we cannot effectively
protect cache access with a VOLUME_LOCK (since there is no single volume name
to grab the lock on while listing all tenants). The original intent of this
jira is to iterate cache to guarantee strong consistency on listTenant
operation. However, since strong consistency can still not be guaranteed
without grabbing a read lock in this case, it would not be much better even if
we add the cache iteration.
As a result, listTenant operation is eventual consistent. There could be a few
seconds of delay before the entries are flushed to the RocksDB table, which
should be acceptable in a typical use case.
> [Multi-Tenant] Properly iterate cache and table in OzoneManager#listTenant
> --------------------------------------------------------------------------
>
> Key: HDDS-6274
> URL: https://issues.apache.org/jira/browse/HDDS-6274
> Project: Apache Ozone
> Issue Type: Sub-task
> Affects Versions: HDDS-4944
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
>
> This is one of the important TODO items left in the code. See:
> https://github.com/apache/ozone/blob/f2fdf046662c/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/OzoneManager.java#L2966
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
