应用：
我有一个 Java 应用程序，其输入中有尖峰/突发，代表事件。每个事件总是有一个读取，一个决策（逻辑），然后基于该决策可能的写入（插入或更新）。大多数读取不会导致日常写入（插入/更新）。从理论上讲，这对于 DAX 和 DynamoDB 来说是一个很好的方案，具有按需计费/配置。
场景/问题：
当发生恰好由写入峰值组成的突发时，我们有时（但不总是）会看到通用 AmazonClientException 实例的峰值。异常有一个retry（即isRetry()），false根本原因是具有通用消息值/字符串的 InternalServerException 实例，其中包括有 500 响应的文本（没有额外的细节或清晰度）。
这些 DAX 异常及其堆栈跟踪确实无法深入了解其真正原因（例如，节流、调整大小之前的临时供应吞吐量异常、主机不可用等）。这似乎是来自 DAX 的意外响应行为，似乎是 DynamoDB On-Demand 调整大小对我来说（有关更多提示，请参阅下面的其他信息），但是当它们确实发生时，我仍然对这些原因的一些损失/不清楚针对这种情况。
附加信息：
- 我正在使用 Java DAX 客户端的最新可用实例。
- 在突发之外，读/写是连续成功的。这包括在受控测试用例中使用事件/数据创建慢速馈送时，这些馈送是在先前在突发中创建异常时捕获的。
- 使用 Provisioned（不是 On-Demand）时，我们看不到这些模糊的客户端异常。我们确实看到了来自 DAX 的吞吐量达到异常，正如对于相同的突发/峰值场景所预期的那样，并根据这些异常
isRetry()（即true）使用成功的退避重试策略来识别我们可以/应该重试。