E-MapReduce：JindoSDK訪問OSS出現Reached timeout問題

具體報錯

[ErrorCode] : 25201 , [ErrorType]: OSS Op Error. [ErrorMessage]: [E1008]Reached timeout=30000ms

解決思路

異常棧有Rename字樣

• 異常樣本

  java.io.IOException: rename src:oss://bucket.oss-cn-xxxx-internal.aliyuncs.com/user/hive/warehouse/tmp/hive/xxxx/c185ce78-f843-4104-8dca-f5b96fc9****/hive_xxxx_00-07-51_265_5593904247532586093-47957/_tmp.-mr-10006, dst:oss://bucket.oss-cn-xxxx-internal.aliyuncs.com/user/hive/warehouse/tmp/hive/xxx/c185ce78-f843-4104-8dca-f5b96fc9****/hive_xxxx-07-21_00-07-51_265_5593904247532586093-47957/_tmp.-mr-10006.moved
  
  ,java.io.IOException: [ErrorCode] : 25201 , [ErrorType]: OSS Op Error. [ErrorMessage]: [E1008]Reached timeout=30000ms @100.118.xx.xx:80 ERROR_CODE : 1008

• 異常原因

  JindoSDK的OSS Rename基於OSS CopyObject實現，此異常通常是CopyObject沒能進行OSS內部的fastcopy最佳化，導致JindoSDK的rename逾時。

• 解決方案：

  可聯絡OSS的支援人員， 確認bucket.oss-cn-xxx-internal.aliyuncs.com設定要求，排查OSS內部的fastcopy最佳化失效原因。

  fastcopy目前僅支援在標準儲存下對大部分普通對象進行重新命名操作。但對於非標準類型的儲存或某些特殊對象，fastcopy無法進行有效最佳化，可能導致在高壓力情況下重新命名操作逾時。因此，建議使用JindoSDK上傳至OSS的普通檔案，並確保檔案使用標準儲存類型。以下情況可能導致fastcopy最佳化失效：

  • 非標準類型的儲存，例如低頻、歸檔、冷歸檔等。

  • OSS的AppendableObject類型的對象。

  • 通過非MultiPart介面上傳的較小對象。

  • 使用了服務端加密等功能的對象。

  • 特殊類型的對象，例如LINK、SYMLINK、DELETEMARKER等。

異常棧有InputStream或Read字樣

• 異常樣本

  Read from oss://xxxx with error message:  [HostId]: oss-cn-zhangjiakou-internal.aliyuncs.com [ErrorMessage]: [E1008]Reached timeout=30000ms

• 異常原因和解決方案

  • JindoData 4.0.0版本的Seek Read存在缺陷，如果您使用的是該版本，請將JindoData升級到4.3.x及以上版本，詳情請參見EMR叢集JindoSDK升級流程。

  • 觸發了OSS的頻寬流控，可聯絡OSS支援人員查看流控原因。

異常棧有OutputStream、Write或Close字樣

• 異常樣本

  com.aliyun.emr.fs.oss.commit.magic.JindoOssMagicOutputStream.write(JindoOssMagicOutputStream.java:146)
          ... 14 more
  Caused by: java.io.IOException: ErrorCode : 25201 , ErrorMsg: OSS Op Error.  [HostId]: oss-cn-beijing-internal.aliyuncs.com [ErrorMessage]: [E1008]Reached timeout=30000ms @100.118.xx.xx:80 ERROR_CODE : 1008
          at com.alibaba.jboot.JbootFuture.get(JbootFuture.java:179)
          at com.alibaba.jboot.JbootOssWriter.write(JbootOssWriter.java:85)

  或

  Caused by: java.io.IOException: Close stream oss://xxx error java.io.IOException: [ErrorCode] : 25201 , [ErrorType]: OSS Op Error.  [HostId]: xxx [ErrorMessage]: [E1008]Reached timeout=30000ms @xxx ERROR_CODE : 1008

• 異常原因和解決方案

  通常是觸發了OSS的頻寬流控，可聯絡OSS支援人員查看流控原因。

異常棧有getFileStatus字樣

• 異常原因

  通常是由於Bucket開啟了多版本功能。

• 解決方案

  1. 需確認是否開啟或曾經開啟過多版本功能。

  2. 聯絡OSS支援人員，確認該Bucket或路徑下是否有10萬以上的DeleteMarker，如果有則需要進行清理。

rm命令

• rm命令帶skipTrash

  該命令內部會有兩個執行階段，首先會執行getFileStatus操作，然後執行delete操作。如果執行該命令出現逾時問題，逾時主要發生在命令內部的getFileStatus階段，您可以通過解決getFileStatus逾時的方法，解決該命令的逾時問題，詳情請參見上文異常棧有getFileStatus字樣。

• rm命令不帶skipTrash

  該命令內部會有兩個執行階段，首先會執行getFileStatus操作，然後執行Rename操作。如果執行該命令出現逾時問題，您可以通過getFileStatus和Rename解決逾時的方法，解決該命令逾時問題，詳情請參見上文異常棧有getFileStatus字樣和異常棧有Rename字樣。

ls命令

ls命令內部會有兩個執行階段，首先會執行getFileStatus操作，然後執行listDirectory操作。如果執行ls命令出現逾時問題，逾時主要發生在內部的getFIleStatus階段，可以通過getFIleStatus解決逾時的方法，解決ls命令逾時問題，詳情請參見上文異常棧有getFileStatus字樣。