0

如果我的理解是正确的，来自 JSR352 第8.2.1.4.4 Default Retry Behavior - Rollback部分：

当发生可重试异常时，批处理运行时的默认行为是回滚当前块并使用 item-count 为 1 和检查点策略 item 重新处理它

以及从第8.2.1.4.3 节重试并跳过相同的异常：

这允许最初为整个块重试异常，然后如果它再次出现则跳过它。

因此，我的期望是，如果发生可重试和可跳过的异常，则“当前”块将回滚并以项目计数 1 重新启动，并跳过此“增量重放周期”内的任何错误。

随后，一旦达到块大小，处理将返回到配置的大小（继续标准处理）。

我观察到一些意外行为，其中“失败的块”被完全跳过，增量处理从后续块开始。因此，我缺少（一大块）记录。

例如，记录计数从下面的 341900 移动到 342001（错过了 341901-342000 的处理）：

2022-02-11 16:09:19,233 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341400
2022-02-11 16:09:20,400 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341500
2022-02-11 16:09:21,503 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341600
2022-02-11 16:09:22,692 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341700
2022-02-11 16:09:23,836 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341800
2022-02-11 16:09:24,954 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341900
2022-02-11 16:09:24,995 INFO  [com.MyClass] (executor-thread-0) Closing resource https://example.com/file.xml
2022-02-11 16:09:24,996 INFO  [com.MyClass] (executor-thread-0) Opening resource https://example.com/file.xml
2022-02-11 16:09:31,847 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342001
2022-02-11 16:09:31,868 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342002
2022-02-11 16:09:31,888 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342003
2022-02-11 16:09:31,906 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342004

我的理解在这里是否正确，如果是这样，这看起来像一个错误还是我在 ItemReader#checkpointInfo() 中遗漏了一些“用户义务”。

jberet-core版本是1.4.4.Final，来自：

<dependency>
    <groupId>io.quarkiverse.jberet</groupId>
    <artifactId>quarkus-jberet</artifactId>
    <version>1.0.0</version>
</dependency>

谢谢

4

0 回答 0