xiaoyuyao commented on a change in pull request #71: HDDS-2344. Add immutable
entries in to the DoubleBuffer for Volume requests.
URL: https://github.com/apache/hadoop-ozone/pull/71#discussion_r338715495
##########
File path:
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/volume/OMVolumeSetOwnerRequest.java
##########
@@ -171,7 +171,8 @@ public OMClientResponse
validateAndUpdateCache(OzoneManager ozoneManager,
omResponse.setSetVolumePropertyResponse(
SetVolumePropertyResponse.newBuilder().build());
omClientResponse = new OMVolumeSetOwnerResponse(oldOwner,
- oldOwnerVolumeList, newOwnerVolumeList, omVolumeArgs,
+ oldOwnerVolumeList, newOwnerVolumeList,
+ (OmVolumeArgs) omVolumeArgs.clone(),
Review comment:
bq. other thread which is performing removeAcl is updating the same
OmVolumeArgs on this(Like we have a list and map internally for acls)
We've already done defensive copy for get Java object of Volume/Bucket/Key
from DB and converted the client provided acl from protobuf when creating
OMxxxAclRequest. I think we should trace down the real cause of the CME here.
Generally, I agree making object immutable is a good thing. However,
unnecessary clone object has performance implications that we should be
cautious.
bq. when flush happens we might flush these entries to rocksdb when some
other operation is changing the same entry which might be still submitted/not
submitted to doublebuffer flush thread.
omVolumeArgs/KeyInfo/BucketInfo are created per request from DB like below:
omVolumeArgs = omMetadataManager.getVolumeTable().get(dbVolumeKey);
Can you elaborate on the operation that could change the per request created
volume/bucket/key object?
----------------------------------------------------------------
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
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
