sodonnel opened a new pull request, #7405: URL: https://github.com/apache/ozone/pull/7405
## What changes were proposed in this pull request? 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 (de-serialized 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 de-serializing 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 APIs and eventually remove KeyEntityInfo from the system. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-11660 ## How was this patch tested? Existing tests cover this, as the changes are internal to the API implementation -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
