TransactionManager 분리 에 대해서 이해가 잘 가지 않는게 있어. 실제 운영 환경에서는 배치와 비즈니스 데이터 DB를 분리하는게 필수라고 했잖아? 근데 이 분리의 단위가 배치용 메타데이터 저장만 분리를 하는게 맞는거야? 현재 사이드 프로젝트에서 멀티모듈 구조에 (MSA는 아님) API 모듈과 배치 모듈을 따로 분리한 상태야. 유저 데이터에서 생일을 뽑아서 내일 생일인 유저에게 FCM 을 발송하는 배치를 만드는데, 이때 만들어준 예제처럼 @BatchDataSource와 비즈니스 로직용 @Primary DataSource를 분리하게 되면, API 모듈용 DB Connnection을 배치에서도 똑같이 갖다 쓰는거 아니야 ?? 즉, 배치에서 API 쪽 커넥션을 가져다 써서 배치가 돌 때 커넥션이 고갈날 수 있지 않을까? 라는 생각이 들었어 지금 이해한 바로는 @BatchDataSource, @BatchTransactionManager를 분리하고 주입해줘도 Reader -> Processor -> Writer 에는 @Primary 걸 쓰는것 같은데 맞아 ? 나는 DB 분리와 함께, 비즈니스 로직에 대한 커넥션, 트랜잭션도 배치용으로 분리하고 싶은데 이럴땐 어떻게 해야해? 특히나 배치에서도 JpaTransactionManager를 쓰고 싶은 경우에는 어떻게 해야해 ? 원하는 바는, API 처리용 DB 커넥션은 커넥션대로 있고, 배치 메타데이터용 커넥션 따로, 배치에서 라이브 DB에서 유저 데이터를 가져오는 커넥션 따로 구성하고 싶어 (배치가 API 모듈 에 영향을 주지 않았으면 해서,,,) 혹시 내가 강의를 제대로 이해를 못한거라면 알려줘
킬구형 강의 자료 중간에 이상한 문구 발견해서 제보해 강의 회차: 5장. 작전4: Flow - 배치의 흐름을 지배하라 (분기점에서 생사를 쥐락펴락하라 ☠ 🏴☠ ) 이상한 문장: 즉, Spring Batch의 암시적 전환 규칙 대상에서 제외된다는 뜻이다. 재시도 Claude는 실수를 할 수 있습니다. 응답을 반드시 다시 확인해 주세요. 강의 자료 중간에 LLM에서 가져온 내용을 잘못 편집한 것 같아.
가령 다음과 같이 g etExecutionContextSerializer() 메서드를 오버라이드하면 g에 볼드처리안됨 -- 원시적 침투 예제의 BatchConfig에서 DefaultBatchConfiguration 상속을 제거하고@EnableBatchProcessing을 추가하자. 다음과 같이 말이다. 예제 밑의 예제가 그냥 기존 DefaultBatchConfiguration 방식만 나와있음 아마 기존과 수정을 두개 다 표시하는식으로 하고싶었을거같음 -- JobContext/StepContext: Late-Binding의 최종 무기고 키룩형 JobContext/StepContext가 존재하면 배치 스코프가 활성화된 상태라는 것은 알겠어. 근데 이 JobContext/StepSontext 대체 어디에 써먹는거지? 단순히 활성화를 의미하는게전부인가? 키룩형 -> 갈매기가 되고싶은 내면의 소리일수있음 괜찮음 주변에 돌멩이 지망생도 있고 독수리 지망생,딸기우유 지망생도 있어서 이해할수있음
SimpleStepHandler - Step 실행의 관리자 Step의 실행은 StepHandler에 의해 의해 통제된다. Spring Batch는 기본 구현체로 SimpleStepHandler를 사용하는데, 이 컴포넌트가 Step 실행의 전체 라이프사이클을 관리한다. 의해 의해 <- 그리고 Step Squad 핵심 요약 있으니까 너무좋은데 Job Squad 에서도 핵심요약이 있었으면 더 좋았을거같음 뭐 스탭이나 잡이나 내용이 거의 비슷비슷하긴한데(Execution 반드시 새거만들고,상태변경시 즉시 메타데이터저장소에 저장하고) 그래도 실제 실행 따라가는 느낌이라 정리가 잘 안되는느낌이긴해서 마지막에 방점찍으면 보기 더 편할거같은느낌
반말은 조금 부끄러워서.. 존댓말로 질문드리겠습니다. ItemWriter에서 예외 발생 시 재시도 - 청크 단위로 재시도 관리 1. ItemWriter에서 예외 발생 시 ItemProcessor부터 처리가 재개된다. 2. ItemProcessor에서와 달리, ItemWriter에서의 재시도 횟수는 청크 단위로 관리된다. 요 부분에서 실제로 배치를 돌려보니 writer부터 재시작하는 것을 확인 가능했습니다.. 관련해서 원인을 분석해보니, 아래 결론에 도달했는데 맞을까요? processorNonTransactional() 설정이 켜져있으면 Item 단위로 처리 결과를 캐시에 저장하기때문에 processor는 모두 완료 처리 -> writer부터 시작 processorNonTransactional() 설정이 꺼져있으면 청크 단위로 완료 처리하기때문에 processor부터 다시 시작
킬구형, 청크 지향 처리 시 벌크 read를 할 수 있는 방법이 있어? ItemReader 사용 시 소스에서 1건 씩 데이터를 읽어온다면, 단건 SELECT문이 매번 날아가거나 아니면 JDBC의 ResultSet next()를 사용하는 것 같은데,, 전자면 DB 부하가 너무 심하고 후자여도 네트워크 IO가 꽤 발생할 것 같은데.. 지금 수백? 수천만? 건 정도의 데이터를 마이그레이션 해야하는 업무를 받았는데, 청크 생성 시 DB 부하나 네트워크 트래픽을 좀 줄이고 싶은데 다건 SELECT를 통해 처리하는 방법이 있을까?
오타 발견 root@4ea86c29f1f7:/data# redis-cli set attack:2 "{\"id\":2,\"timestamp\":\"${TODAY}T09:28:47\",\"targetIp\":\"203.0.113.50\",\"attackType\":\"XSS\",\"payload\":\"<script>alert('HACKED!');</script>\"}" 위 명령어 실행 시, 아래와 같은 에러 메시지 발생! bash: !': event not found 에러 발생 원인 bash: !': event not found 에러는 Bash의 히스토리 확장(history expansion) 때문에 납니다. ! 문자(예: HACKED! )가 들어가면 bash가 ! 로 시작하는 히스토리 토큰(예: !! , !$ , !123 )으로 해석하려 하고, 매칭되는 히스토리 항목이 없으면 event not found 오류가 납니다. set +H # 히스토리 확장 끄기 ... redis-cli set attack:2 "{\"id\":2,\"timestamp\":\"${TODAY}T09:28:47\",\"targetIp\":\"203.0.113.50\",\"attackType\":\"XSS\",\"payload\":\"<script>alert('HACKED!');</script>\"}" ... set -H # # 히스토리 확장 켜기 OK redis key들을 set 하기 전에 히스토리 확장을 끄고 실행할 경우 정상 동작
강의 예제를 따라가면서 SystemFailureJobConfig 배치를 실행했는데, 계속 FlatFileItemReader에서 JobParameter로 전달한 inputFile이 null로 들어오는 문제가 발생했다. 정확하게는 Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.batch.item.file.FlatFileItemReader]: Factory method 'systemFailureItemReader' threw exception with message: Path must not be null 이 오류 였으며, public FlatFileItemReader<SystemFailure> systemFailureItemReader( @Value("#{jobParameters['inputFile']}") String inputFile) { log.info("오잉 Reader inputFile: " + inputFile); // null return new FlatFileItemReaderBuilder<SystemFailure>() .name("systemFailureItemReader") //여기서 path not null 오류 발생 .resource(new FileSystemResource(inputFile)) .delimited() .delimiter(",") .names("errorId", "errorDateTime", "severity", "processId", "errorMessage") .targetType(SystemFailure.class) .linesToSkip(1) .build(); } .name("systemFailureItemReader") 이 위치에서 발생하고 있었다. 그리고 line numbers are likely diverged. try to find the current location inside 'SystemFailureJobConfig. systemFaliureItemReader()' 이 메시지도 함께 보였다. GPT에 물어봐서 해결이 되긴 했는데, KillBatchSystemApplication에서 CommandLineRunner를 구현하고 직접 경로를 지정해주었다. @SpringBootApplication @AllArgsConstructor public class KillBatchSystemApplication implements CommandLineRunner { private final JobLauncher jobLauncher; private final Job systemFailureJob; public static void main(String[] args) { SpringApplication.run(KillBatchSystemApplication.class, args); } @Override public void run(String... args) throws Exception { JobParameters params = new JobParametersBuilder() .addString("inputFile", "/Users//Desktop/kill-batch-system2/system-failures.csv") .toJobParameters(); jobLauncher.run(systemFailureJob, params); } } 실무에서는 CLI로 파라미터를 전달하는것이 핵심이라 했던걸로 기억한다. CLI로 전달한 JobParameter를 StepScope Bean에서 안전하게 받는 다른 방법은 없나?? 아 지금 작업도구는 MacOS M1, Spring Boot 3.4.7 이다. 연휴 잘 보내길 바란다.
청크 단위로 트랜잭션 된다는건 이해했다. 그에 관련해서 궁금증이 생겼는데, reader, processor에서 처리하다가 Exception이 나도 사실 DB엔 롤백할게 없으니 사실상 Writer 작업 중에만 단 한번 롤백이 수행될 것이라고 예상되는데 맞는가? read 시에, process 도중에도 롤백이 일어날 경우가 있는지 궁금하다. 추가로 과거 스프링 배치 공식 문서의 잘못된 다이어그램 이라던지 null을 줘야 끝난다는 점과 97개 와 같이 자세한 예시를 들어준 점, read(), process()가 각각 10번씩 수행된다는 것과 같이 사용자들이 많이 헷갈려 하는걸 명확하게 알려줘서 좋은 것 같다.
앞선 질문에 대한 답변 고맙다 미스터 KILL-9 덕분에 손쉽게 엑셀을 처형 (처리)할 수 있었지 하지만 그 다음 관문이 존재하는군 후후.. 각 STEP 마다 RepeatStatus 에 따라서 트랜잭션이 보장하는건 이해했다 하지만 여러 관계가 존재하는 테이블 데이터 적재 시 트랜잭션을 어떻게 보장할지 감이 안온다 미스터 KILL-9 예를 들어 설명하지.. FILE-A, FILE-B 각각 다른 컬럼을 가진 파일들이지 FILE-A는 TABLE-A에 적재하고 FILE-B는 TABLE-B에 적재한다 각 FILE 당 ROW 100개씩 읽으면서 적재하고 문제가 생기면 해당 100건만 롤백할텐데 문제는 TABLE-A 와 TABLE-B의 관계다 TABLE-A 가 부모고 TABLE-B자 자식 테이블인 상황에서 특정 TABLE-B 데이터 롤백 시 TABLE-A 데이터도 마찬가지로 롤백 해야할거 같은데 이런 경우 어떻게 원자성을 보장할 수 있는가에 답변할 수 있겠는가..? 현재 내가 떠오른 방안은 결국은 모든 데이터 처리이니 특정 부분 처리 실패하면 데드 DLQ (Dead Letter Queue) 에 담아서 나중에 처형( 처리)하도록 해야하나 싶다!
Spring Boot + Kotlin + java 21로 진행중이다. 먼저 좋은 강의 너무 고맙고, 나도 다른 사람의 Q&A 처럼 BatchConfig가 있어서 수행시에 부트만 떴다가 꺼지고 아무것도 출력되지 않아서 당황했다 (그래서 강의 자료에 더이상 불필요하다 보다는 제거하라고 명시하면 좋을 것 같다) 질문이 있는데 1. BatchConfig가 있고 없고가 어떤 것 때문에 수행결과에 차이점을 주는거야? 2. Kotlin을 사용한 Spring Boot에서는 @Import를 사용하지 않았는데, 이때도 자동으로 설정을 해주는걸까? BatchConfig가 있다는 것 자체로 배치 수행은 안하고 부트가 바로 끝나버려 두 질문 다 그냥 궁금증일 뿐이다. BatchConfig를 제거하면 수행에는 문제가 없다.
킬구형 안녕 FlatFileReader 라는 아주 편안한 기능은 존재하는데 어째서 ExcelFileReader 기능은 존재하지 않는거지? gpt 말로는 공식 확장 모듈은 spring-batch-excel 이 존재한다고는 하는데 이거 믿고 사용해도 되는지 모르겠네 킬구형은 excel 파일 읽고 DB에 쓸 때 아파치 poi 라이브러리로 직접 파싱해?
InFearLearn 서버 침입 사건: 해커 패턴 추적 작전 작전 수행을 위한 실전 코드부터 살펴보자. 여기코드에서 @Bean @StepScope public MongoCursorItemReader<SecurityLog> securityLogReader( 이 아이템리더쪽 복붙하고 안다듬어서 들여쓰기 밀림
공부중인데 내용이 너무 좋아서 블로그에 공부한 예제 코드와 정리된 내용을 일부 작성하려 하는데 괜찮을까요?? 스크린샷으로 첨부하거나 그런건 아니고 코드는 제 ide 에서 실행한것과 git repo 에 올리면서 공유하려고 해~ 그리고 공부한 내용들은 직접 작성 하고 정리해서 올리려고 하는데 괜찮은지 궁금해서 질문해!!
1.오타 JobScope와 StepScop가 선언된 빈은 애플리케이션 구동 시점에는 우선 프록시 객체로만 존재한다. 그 후 Job이나 Step이 실행된 후에 프록시 객체에 접근을 시도하면 그 때 실제 빈이 생성된다. StepScop <-오타 2.건의(내가틀렸을수도있음 그러면 수정해주셈) 그리고 JobParameters가 잡 실행 내부에서 불변이라는 내용이 필요할거같음 배치쓰던사람들은 당연한거라 생각할수있는데(잡파라미터랑 잡이름으로 유니크체크한댔나 그런거도 있으니까) 배치 첨쓰는사람은 왜 잡파라미터가 있는데 ExecutionContext를 사용하지 라는 생각을 할수있을거같음 3.궁금증 컴파일 시점에 없는 값을 어떻게 참조할 것인가? 여기서 잡의 스텝생성시점에서 di받는 잡파라미터 자리에 null을 넣는식으로 처리하는 방법이 있다고했는데,만약 코틀린의 경우엔 명시적으로 잡파라미터를 ?를 붙여서 nullable로 선언하고 로직에서 NullSafe 박는식으로밖에 해결할수없고 저게 맘에안들면 빈주입해야함? 저런 null전달같은 꼼수딴거없음? 강의가 자바기반이라고 적혀있어서 물어봐도되나싶긴한데 예전에 저것땜에 고생했었는데 다른방법을 못찾아서 물어봄
