jclouds：getBlob 上的 getBucketLocation 超时答案

【问题标题】：jclouds: getBucketLocation timeout on getBlobjclouds：getBlob 上的 getBucketLocation 超时
【发布时间】：2022-09-30 07:34:55
【问题描述】：

我正在使用 jclouds 2.5.0。它在我们所有的部署中都运行良好，除了一个。在这种情况下，我们会在 log4j2 日志中看到以下 jclouds 消息：

2022-07-14 21:37:29.263 +0000,3124098302712886 {} ERROR o.j.h.h.BackoffLimitedRetryHandler [clrd-highpri-1] Cannot retry after server error, command has exceeded retry limit 5: [method=org.jclouds.aws.s3.AWSS3Client.public abstract java.lang.String org.jclouds.s3.S3Client.getBucketLocation(java.lang.String)[hammerspace-data-bucket-us-west-2], request=GET https://s3.amazonaws.com/hammerspace-data-bucket-us-west-2?location HTTP/1.1]

此消息发生在 getBlob 调用期间，因此我假设 getBlob 的一部分是确定应从中检索 Blob 的存储桶。这个调用失败了 5 次——但不仅仅是因为返回码错误而失败——它挂起并超时，所以这 5 次重试占用了下载 blob 所需时间的大部分时间。

在 getBlob 最终停止调用 getBucketLocation 后，它会尝试使用默认区域 (us-east-1) 进行下载。由于存储桶实际上位于 us-west-2 中，因此下载所需的时间比应有的要长一些，但是 - 再次 - 实际的下载瓶颈是对 getBucketLocation 的失败调用。

有没有人见过这样的事情？

我也有兴趣知道如何打开更多的 jclouds 日志记录。我曾经在我的 log4j2.xml 文件中取消注释这样的行：

        <!-- <logger name=\"org.jclouds\" level=\"debug\" additivity=\"true\" /> -->
        <!-- <logger name=\"jclouds.compute\" level=\"debug\" additivity=\"true\" /> -->
        <!-- <logger name=\"jclouds.wire\" level=\"debug\" additivity=\"true\" /> -->
        <!-- <logger name=\"jclouds.headers\" level=\"debug\" additivity=\"true\" /> -->
        <!-- <logger name=\"jclouds.ssh\" level=\"debug\" additivity=\"true\" /> -->
        <!-- <logger name=\"software.amazon.awssdk\" level=\"debug\" additivity=\"true\" /> -->
        <!-- <logger name=\"org.apache.http.wire\" level=\"debug\" additivity=\"true\" /> -->

但这些似乎在 2.5.0 中不再有任何影响。

最后，如果有人知道如何阻止 getBlob 调用 getBucketLocation，我将非常感谢您提供一些建议。我认为必须有一种方法可以预先为 jclouds blob 上下文指定所需的存储桶，这样就不必解决它。

约翰

[更新 1]

我们最初认为问题是我们没有为存储桶正确配置 AIM 配置文件，但是在使用它之后，我们能够从该存储桶上的同一主机运行 AWS 命令行工具，但它没有挂起，但 jclouds 仍然挂在同一个盒子上的 getBucketLocation 上。我完全被这个难住了。它必须是 AWS 提供商的 jclouds 2.5.0 内部的东西。

标签： amazon-s3 timeout freeze jclouds

【解决方案1】：

我发现了这个问题的根本原因，并认为可能还有其他人想知道发生了什么。

Amazon 发布了一个通用工作流程，允许客户端始终为给定存储桶找到正确的 URL 端点：

向 s3.amazonaws.com 询问存储桶位置
使用返回的 url 发出特定于容器的请求（get/put 等）
如果客户端稍微智能一点，它只会在第一个请求时询问并缓存存储桶位置 URL，并在后续请求中重用它。

如果客户端更加智能，并且它注意到指定了特定于区域的 URL，它将直接使用该 URL 来尝试请求。失败后，它将回调美国西海岸以获取存储桶位置，缓存并使用它。

显然，jclouds 仅处于上述 1 级智能。它完全忽略了指定的 URL，但它至少缓存了第一个 getBucketLocation 调用的结果，并根据需要使用该区域特定的 URL。

在内部，它使用 google guava LoadingCache 进行此过程。如果 jclouds 中有一种机制可以使用给定存储桶的已知区域特定 URL 预加载此缓存，那可能会很好。然后它不必为 getLocation 数据开箱——即使是在第一次请求时也是如此。

我希望这对其他人有帮助。发现确实让我很痛苦。而且由于我没有收到任何 jclouds 邮件列表查询的答案，我不得不假设 jclouds 社区中也没有人了解它是如何工作的。（或者也许我只是没有很好地表达我的查询。）

【讨论】：