应用程序:
我有一个Java应用程序,其输入中包含峰值/爆发,表示事件。对于每个事件,总会有一个读取,一个决策(逻辑),然后根据该决策可能进行写入(插入或更新)。大多数读取操作不会导致每天的写入(插入/更新)。从理论上讲,这是使用按需计费/配置的DAX和DynamoDB的理想方案。
场景/问题:
当确实发生了突发事件,而突发事件恰好由写入峰值组成时,我们有时(但并非总是)看到了泛型AmazonClientException实例的峰值。异常的retry
中的isRetry()
(即false
)和根本原因是InternalServerException实例,该实例具有通用消息值/字符串,其中包括响应为500的文本(否其他细节或清晰度)。
这些DAX异常及其堆栈跟踪确实无法深入了解其真正原因(例如节流,调整大小之前的临时供应吞吐量异常,主机不可用等)。对于DynamoDB按需调整大小,这似乎是DAX的意外响应行为(请参阅下面的其他信息以获取更多提示),但是当它们发生时,我仍然有些失落/不清楚的原因针对这种情况。
其他信息:
isRetry()
(即true
)使用了成功的退避重试策略,确定我们可以/应该重试。