У меня есть пакет, реализованный с JSR-352 (с использованием jberet на wildfly).
У меня есть блок с количеством элементов 15, а java.lang.Exception настроен как исключение с возможностью повторной попытки и пропуска.
Когда есть много исключений, большинство элементов будет обрабатываться несколько раз. В этом крайнем случае все элементы вызовут исключение в модуле записи:
- Прочитаны первые 15 заданий
- Исключение происходит на первом элементе
- Чанк откатывается и настраивается с помощью item-count = 1
- Читается первый элемент
- Исключение снова возникает, элемент пропущен
- Продолжите с остальными 14 элементами, исключение может произойти для каждого элемента, каждый элемент пропускается.
- После первых 15 элементов чанк возвращается с количеством элементов = 15
- Пункты 16-30 читаются
- Исключение снова возникает
- Читатель откатился до последней контрольной точки
На данный момент еще нет контрольной точки, потому что еще не было успешно обработанного элемента. Следовательно, читатель снова начинает с первого пункта. Все 30 элементов обрабатываются со значением item-count = 1. и т. Д.
Если таких отказов будет много, партия будет обрабатывать все элементы снова и снова.
Я думаю, что контрольную точку нужно установить также для пропущенных элементов, потому что пропущенный элемент не должен обрабатываться снова.
Я думаю, что это ошибка спецификации, поэтому я уже открыл там проблему: https://github.com/WASdev/standards.jsr352.batch-spec/issues/15 Или я ошибаюсь и неправильно понял реализацию?
Как это реализовано в Spring Batch?
