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字样。