[ 
https://issues.apache.org/jira/browse/HDDS-11660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated HDDS-11660:
----------------------------------
    Labels: pull-request-available  (was: )

> Recon List Key API: Reduce object creation and buffering memory
> ---------------------------------------------------------------
>
>                 Key: HDDS-11660
>                 URL: https://issues.apache.org/jira/browse/HDDS-11660
>             Project: Apache Ozone
>          Issue Type: Improvement
>          Components: Ozone Recon
>            Reporter: Stephen O'Donnell
>            Assignee: Stephen O'Donnell
>            Priority: Major
>              Labels: pull-request-available
>
> The current ListKeysAPI implementation, pulls a batch of OMKeyInfo objects 
> from the File / Key table and buffers them in an array.
> Then it converts each item in that array to a KeyEntityInfo object, which has 
> JSON annotations allowing the data to be serialized over HTTP.
> This results in two copies of the objects buffered in memory at once.
> Additionally, the OMKeyInfo object is a fairly heavyweight object, and 
> creating it from protobuf also deserialized the block information, which is 
> not needed for the ListKey purposes.
> Further taking the protobuffer bytes from RocksDB creates a KeyInfo object 
> (deserialized proto) and then this object is copied into OmKeyInfo.
> So for each key retrieved, we start with:
> 1. A deserialized proto object (KeyInfo)
> 2. A copy of the proto fields (OmKeyInfo)
> 3. A json annotated object (KeyEntityInfo).
> By deserializing into the 3rd object directly, and having it wrap a keyInfo 
> object and delegate calls to it when appropriate, we avoid needing the 
> heavyweight OmKeyInfo object, and make the KeyEntityInfo object "slimmer". We 
> can also avoid the double buffering, creating only a single list of objects 
> for the batch.
> This PR introduces a KeyEntityInfoProtoWrapper object, rather than changing 
> the existing KeyEntityInfo object. The reason, is that other APIs outside of 
> ListKeys use it. I am not ready to change those APIs now, however after this 
> change gets committed and we are happy with it, it should be possible to 
> apply similar changes to those other API and eventually remove KeyEntityInfo 
> from the system.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to