인프런 커뮤니티 질문&답변
작성한 질문수
retry count 관련 질문
작성
·
28
0
안녕하세요 강사님 좋은 강의 감사드립니다.
해당 RetryListener 예제에서 조금 이해되지 않는 부분이 있어 글 남깁니다.
CustomItemProcessor에서 아이템이 2일 때 예외가 1번 발생하고 CustomItemWriter에서도 아이템이 2일 때 예외가 1번 발생(예외 총 2번 발생)
CustomRetryListener의 onError() 메소드가 총 2번 호출되는데 두 번째 호출될 때 context.getRetryCount()가 2로 찍혀야 되는 것이 아닌가 생각이 들었습니다.
제가 해당 예제를 따라서 실습할 때도 그렇고 강의 화면을 봐도 retry count가 모두 1로 찍히고 있습니다.
동일한 아이템이어도 process할 때와 write할 때 retry count가 다르게 적용되는 것일까요..?
확인해주시고 답변 주시면 많은 도움이 될 것 같습니다.
감사합니다.
답변 2
1
아래 답변에서 정확한 설명을 해 주고 있습니다.
사실 재시도라는 의미를 잘 해석해 보면 똑같은 것을 여러번 반복한다는 의미를 내포하고 있습니다.
그리고 재시도는 독립적이어야 하고 다른 것에 영향을 받아서도 주어서도 안되는 특징을 가지고 있습니다.
가령 네트워크 오류가 나서 잠시 인터넷이 안되는 상황이 발생했을 때 몇 번 시도하다보면 다시 네트워크가 정상으로 돌아오는 시점에 인터넷이 원복될 수 있습니다. 이 때 재시도 하는 주체는 독립적이고 다른 주체와 내용이나 결과를 공유하거나 하지 않습니다.
마치 이와 같이 Processor 와 Writer 는 재시도하는 주체가 다르기 때문에 모든 과정과 결과와 내용도 독립적으로 이루어지고 보관하게 됩니다.
스프링 배치가 이런 전략을 쓴다기 보다는 재시도라는 개념 자체가 이런 특성을 가지고 있다고 보시면 됩니다.
1
안녕하세요, 인프런 AI 인턴입니다.
chaelynjang 님의 질문에 대해 도움을 드리고자 합니다. RetryListener에서 동일한 아이템에 대해 프로세스 단계와 쓰기 단계에서 각각 예외가 발생할 수 있고, 이로 인해 context.getRetryCount()가 다르게 보이는 현상에 대한 궁금증을 해결해 드리겠습니다.
스프링 배치의 Retry 메커니즘에서는, 프로세스 단계와 쓰기 단계가 각각 자신의 Retry 상태를 유지합니다. 이는 각 단계가 서로 다른 컨텍스트에서 실행되며, 각각의 RetryContext를 갖기 때문입니다. 따라서, 동일한 아이템이라도 프로세스 단계의 RetryCount와 쓰기 단계의 RetryCount가 다르게 기록될 수 있습니다.
이 경우:
- CustomItemProcessor에서 예외가 발생했을 때, 그 단계에 대한 RetryCount가 계산되고,
- CustomItemWriter에서 또한 예외가 발생했을 때, 다시 초기화된 새로운 RetryContext에서 Retry count가 다시 시작되는 것입니다.
이 점이 혼동을 줄 수 있지만, 이는 스프링 배치의 의도된 동작입니다. 각 단계의 책임과 컨텍스트가 독립적으로 관리되므로, 예외가 발생한 시점에서 각각의 로직에 따라 Retry가 이루어지는 것이기 때문입니다.
관련된 더 자세한 설명을 원하신다면, 스프링 배치의 공식 문서나 관련 포스팅을 참고하시는 것도 좋은 방법입니다:
- 스프링 배치 공식 문서
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.