具有可重试和可跳过异常的 jsr 352 批处理可能会多次处理项目
jsr 352 batch with retryable and skippable exception may processes items many times
我有一个用 JSR-352 实现的批处理（在 wildfly 上使用 jberet）。
我有一个项目数为 15 的块，java.lang.Exception 被配置为可重试和可跳过的异常。
当异常较多时，大部分项目会被多次处理。在这种极端情况下，所有项目都会在编写器中引发异常：
- 已阅读前 15 项
- 第一项出现异常
- 块被回滚并配置为 item-count = 1
- 已阅读第一项
- 再次出现异常，项目被跳过
- 继续其他14项，每一项都可能出现异常，每一项都跳过
- 在前 15 个项目之后，块返回项目计数 = 15
- 已阅读第 16-30 条
- 再次出现异常
- Reader 回滚到最新的检查点
此时还没有检查点，因为还没有成功处理的项目。因此 reader 再次从第一项开始。所有 30 件物品都以 item-count = 1 处理。等
如果有很多这样的失败，批处理将一次又一次地处理所有项目。
我认为也需要为跳过的项目设置检查点，因为不应再次处理跳过的项目。
我认为这是规范中的一个错误，所以我已经在那里打开了一个问题：https://github.com/WASdev/standards.jsr352.batch-spec/issues/15
还是我错了，误解了实现？
这是如何在 Spring 批处理中实现的？
我认为规范已经足够清楚了，这表明这可能是一个 JBeret 错误（假设它不是应用程序问题）。
在规范（非官方版本here）中，部分：
8.2.1.4.3 Retry and Skip the Same Exception
表示在回滚重试期间，一次处理一个项目（在一个项目块中），并且在重试期间跳过优先。
因此，如果在重试期间发生可跳过的异常，则该项目将被跳过，并且应该保留更新的检查点。这就是我工作的 JSR 352 实现 WebSphere Liberty Batch 的工作方式。
所以我建议制作一个重新创建的项目，如果它看起来仍然像一个 JBeret 问题，则打开一个 JBeret 问题。在这一点上，我没有发现规格问题。
我有一个用 JSR-352 实现的批处理（在 wildfly 上使用 jberet）。
我有一个项目数为 15 的块，java.lang.Exception 被配置为可重试和可跳过的异常。
当异常较多时，大部分项目会被多次处理。在这种极端情况下，所有项目都会在编写器中引发异常：
- 已阅读前 15 项
- 第一项出现异常
- 块被回滚并配置为 item-count = 1
- 已阅读第一项
- 再次出现异常，项目被跳过
- 继续其他14项，每一项都可能出现异常，每一项都跳过
- 在前 15 个项目之后，块返回项目计数 = 15
- 已阅读第 16-30 条
- 再次出现异常
- Reader 回滚到最新的检查点
此时还没有检查点，因为还没有成功处理的项目。因此 reader 再次从第一项开始。所有 30 件物品都以 item-count = 1 处理。等
如果有很多这样的失败，批处理将一次又一次地处理所有项目。
我认为也需要为跳过的项目设置检查点，因为不应再次处理跳过的项目。
我认为这是规范中的一个错误，所以我已经在那里打开了一个问题：https://github.com/WASdev/standards.jsr352.batch-spec/issues/15 还是我错了，误解了实现？
这是如何在 Spring 批处理中实现的？
我认为规范已经足够清楚了，这表明这可能是一个 JBeret 错误（假设它不是应用程序问题）。
在规范（非官方版本here）中，部分：
8.2.1.4.3 Retry and Skip the Same Exception
表示在回滚重试期间，一次处理一个项目（在一个项目块中），并且在重试期间跳过优先。
因此，如果在重试期间发生可跳过的异常，则该项目将被跳过，并且应该保留更新的检查点。这就是我工作的 JSR 352 实现 WebSphere Liberty Batch 的工作方式。
所以我建议制作一个重新创建的项目，如果它看起来仍然像一个 JBeret 问题，则打开一个 JBeret 问题。在这一点上，我没有发现规格问题。