[GitHub] [hadoop-ozone] bharatviswa504 edited a comment on issue #89: HDDS-2322. DoubleBuffer flush termination and OM shutdown's after that. Make entry returned from cache a new copy.

[GitBox <gi...@apache.org>]

bharatviswa504 edited a comment on issue #89: HDDS-2322. DoubleBuffer flush termination and OM shutdown's after that. Make entry returned from cache a new copy.
URL: https://github.com/apache/hadoop-ozone/pull/89#issuecomment-547022709
 
 
   > https://issues.apache.org/jira/browse/HDDS-2356 issue happens here as well. From the stack I got, it looks like it may also be related to partKeyInfoList as TreeMap in OmMultipartKeyInfo.java being not thread safe. I may have little background knowledge here, but from the logs I got after running in actual env, it shows some other errors in https://issues.apache.org/jira/browse/HDDS-2356.
   > 
   > I wonder if we need to stay with TreeMap as a data structure since it's hard to make TreeMap thread safe.
   > 
   > Looks like after this change, there happens another recurring error in VM cluster. Please see https://issues.apache.org/jira/browse/HDDS-2356 for more info. I test several times and unfortunately the new issue seems to persist.
   
   Thank You for trying out the fix. On a bucket, multipart upload complete cannot occur in parallel, as we acquire bucket lock and then perform the operation(during write/get), so I think we don't require TreeMap to be synchronized/thread-safe.
   
   > Looks like after this change, there happens another recurring error in VM cluster. Please see https://issues.apache.org/jira/browse/HDDS-2356 for more info. I test several times and unfortunately the new issue seems to persist.
   This occurs when uploaded parts map is not matching with the parts map for a MPU key. As said in HDDS-2356 jira.
   
   Example: Uploaded MPU key has 1,2,3 as its parts in OM for uploaded Multipart key, whereas different values or greater/less than the size of the entries are specified during complete multipart upload, this error will be thrown.
   
    
   
   And also it helps if you could you provide the steps used to reproduce this error.
   
    
   
   if (partKeyInfoMap.size() != multipartMap.size()) {
    throw new OMException("Complete Multipart Upload Failed: volume: " +
    volumeName + "bucket: " + bucketName + "key: " + keyName,
    OMException.ResultCodes.MISMATCH_MULTIPART_LIST);
   }
   
   
   Actually let me explain before this patch why we are seeing concurrentModificationException error is because, we add entry in to cache, and add the same entry in to OMClientResponse and use that in doubleBuffer flush iteration. But now there can be other thread which can modifiy/update/delete the entry in the cache. To avoid this, this patch proposes when ever the cache returns a value it always get a new object, so the changes happening in other threads will not affect double buffer flush iteration.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org