使用Azure Java SDK v11.0.1传Blob遇TimeoutException，重启恢复求因

使用Azure Storage Blob SDK for Java v11.0.1向Blob存储上传文件时，每周偶尔出现一次超时错误，导致应用中断，重启后恢复正常。报错信息如下：

java.util.concurrent.TimeoutException: The source did not signal an event for 60 seconds and has been terminated.
2023-03-21T10:30:53.721545956Z at io.reactivex.internal.operators.single.SingleTimeout$TimeoutMainObserver.run(SingleTimeout.java:123) ~[rxjava-2.2.9.jar!/:na]
2023-03-21T10:30:53.721551557Z at io.reactivex.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:38) ~[rxjava-2.2.9.jar!/:na]
2023-03-21T10:30:53.721555757Z at io.reactivex.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:26) ~[rxjava-2.2.9.jar!/:na]
2023-03-21T10:30:53.721559957Z at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
2023-03-21T10:30:53.721563857Z at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[na:na]

可能的原因 #

• SDK版本过旧：v11.0.1是较早的版本，后续迭代修复了大量网络超时、连接池管理相关的bug，包括RxJava超时逻辑的优化，旧版本缺乏这些修复，容易在复杂场景下触发超时。
• 默认超时设置不足：SDK默认60秒的超时阈值，在网络波动、Azure存储服务临时负载过高时，上传请求无法在规定时间内完成，触发RxJava的超时终止逻辑。
• 连接池资源耗尽：Spring Boot 2.1.6搭配旧版SDK，可能存在连接池未正确回收连接的问题，长期运行后连接池被占满，新的上传请求无法获取可用连接，最终导致超时。
• 服务端或网络临时故障：Azure存储服务偶尔会出现区域性负载高峰、网络抖动，旧SDK的重试机制不够健壮，无法自动应对这类临时故障，直接触发超时中断。

解决建议 #

• 升级SDK版本：优先升级到v11.x系列的最新稳定版（如v11.22.0），该版本修复了大量已知问题；条件允许的话，建议直接迁移到v12版本，其API设计更现代，性能和稳定性更优。
• 调整超时与重试参数：通过BlobRequestOptions自定义设置更长的超时时间（如setTimeoutIntervalInMs(120000)），同时配置合理的重试策略（如增加重试次数、调整重试间隔）。
• 优化连接池配置：在Spring Boot中调整HTTP连接池参数，比如设置最大连接数、空闲连接超时时间，确保连接资源能及时回收复用。
• 添加业务层重试：在上传逻辑中针对TimeoutException添加重试机制，避免单次超时直接导致应用中断，提升系统容错性。

内容的提问来源于stack exchange，提问作者Yatharth Mishra