[
https://issues.apache.org/jira/browse/HDDS-13365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-13365:
-------------------------------
Description:
We need to ensure that the tables in CleanupTableInfo in OM response should be
exactly the same as the ones updated in the corresponding OM request's
validateAndUpdateCache. Currently, this is done with using CleanupTableInfo on
the OMClientResponse. However, this is hard to keep track because all the cache
updates are done in the OMClientRequest, but we need to update the
OMClientResponse instead. We should couple the table cache update in
OMClientRequest and the tables to cleanup. That way, we remove the
CleanupTableInfo reflection entirely. This also have added benefit of reducing
the overhead introduced by Reflections
(https://stackoverflow.com/questions/435553/java-reflection-performance).
One way is for the OMClientRequest to pass the CleanupTableInfo for the
OmClientResponse whenever a cache is updated. This will ensure that any table
cache updated will be propagated to the OMClientResponse. Moreover, this can
save some cleanup overhead if not all tables in the CleanupTableInfo need to be
cleaned up in certain cases (e.g. OMOpenKeysDeleteRequest might only need to
cleanup only OPEN_KEY_TABLE (if all the open keys are from OBS / LEGACY
buckets) or OPEN_FILE_TABLE (if all the open keys are from FSO bucket) or both.
There might be some overhead when passing the OM table cache to cleanup.
However, current since OMClientRequest#validateAndUpdateCache only returns the
generic OMClientResponse, it might be hard to test this. We might need to
parameterize ( the OMClientRequest (using generic) to pair it with the
associated OMClientResponse implementation. Afterwards, we can list all the
OMClientRequest and check the associated OMClientResponse.
was:
We need to ensure that the tables in CleanupTableInfo in OM response should be
the same as the ones updated in the corresponding OM request's
validateAndUpdateCache. Ideally, CleanupTableInfo should be built by checking
the OMClientRequest#validateAndUpdateCache implementation for any cache update,
instead of hardcoding CleanupTableInfo in the OM response, which is very prone
to human error.
However, current since OMClientRequest#validateAndUpdateCache only returns the
generic OMClientResponse, it might be hard to test this. We might need to
parameterize ( the OMClientRequest (using generic) to pair it with the
associated OMClientResponse implementation. Afterwards, we can list all the
OMClientRequest and check the associated OMClientResponse.
Still thinking on how to check which cache is updated in validateAndUpdateCache.
* One way is for the OMClientRequest to pass the CleanupTableInfo for the
OmClientResponse whenever a cache is updated. This can save some cleanup
overhead if no all tables in the CleanupTableInfo need to be cleaned up in
certain cases (e.g. OMOpenKeysDeleteRequest might only need to cleanup only
OPEN_KEY_TABLE (if all the open keys are from OBS / LEGACY buckets) or
OPEN_FILE_TABLE (if all the open keys are from FSO bucket) or both. However, in
other cases, it's pure overhead.
* We can then remove the CleanupTableInfo reflection entirely. This might
reduce the overhead introduced by Reflections
(https://stackoverflow.com/questions/435553/java-reflection-performance)
> Ensure that CleanupTableInfo in OM response is synced with OM request
> ---------------------------------------------------------------------
>
> Key: HDDS-13365
> URL: https://issues.apache.org/jira/browse/HDDS-13365
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> We need to ensure that the tables in CleanupTableInfo in OM response should
> be exactly the same as the ones updated in the corresponding OM request's
> validateAndUpdateCache. Currently, this is done with using CleanupTableInfo
> on the OMClientResponse. However, this is hard to keep track because all the
> cache updates are done in the OMClientRequest, but we need to update the
> OMClientResponse instead. We should couple the table cache update in
> OMClientRequest and the tables to cleanup. That way, we remove the
> CleanupTableInfo reflection entirely. This also have added benefit of
> reducing the overhead introduced by Reflections
> (https://stackoverflow.com/questions/435553/java-reflection-performance).
> One way is for the OMClientRequest to pass the CleanupTableInfo for the
> OmClientResponse whenever a cache is updated. This will ensure that any table
> cache updated will be propagated to the OMClientResponse. Moreover, this can
> save some cleanup overhead if not all tables in the CleanupTableInfo need to
> be cleaned up in certain cases (e.g. OMOpenKeysDeleteRequest might only need
> to cleanup only OPEN_KEY_TABLE (if all the open keys are from OBS / LEGACY
> buckets) or OPEN_FILE_TABLE (if all the open keys are from FSO bucket) or
> both. There might be some overhead when passing the OM table cache to cleanup.
> However, current since OMClientRequest#validateAndUpdateCache only returns
> the generic OMClientResponse, it might be hard to test this. We might need to
> parameterize ( the OMClientRequest (using generic) to pair it with the
> associated OMClientResponse implementation. Afterwards, we can list all the
> OMClientRequest and check the associated OMClientResponse.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org
For additional commands, e-mail: issues-h...@ozone.apache.org
