어노테이션을 사용한 Listener 를 정의할 때 @Component 어노테이션으로 빈으로 등록시켜줬는데, 실제로 Listener 클래스를 지정할때는 new ServerRackControlListener() 로 직접 생성해주고있네? 빈으로 등록한것과, 직접 생성한 것이 서로 연관되지 않는것 같은데 빈으로 주입받아서 넣어주는게 좋을까 아님 Listener 클래스를 빈으로 등록하지 않고 직접 생성해서 사용하는게 좋을까? 배운대로 Listener 클래스에서 JobExecution 이나 StepExecution 을 사용하는데, Job 실행이나 Step 마다 Execution 이 다를 수 있으니까 빈으로 등록하지 않아도 될 것 같은데 어떻게 생각해?
형 질문이 있어! 형 강의 너무 고마워! 배치에서 리모트 파티션 사용중인데 리모트 파티션을 전달에 쓰이는 내부 큐가 있는걸로 알고 있어! 그 큐가 GC 가 안되어 1주일 정도 넘으면 OOM 이 떨어지는거 같아! 혹시 무언가 놓친게 있을까?? 설정이나 아니면 필요한 부분이? 답변 부탁해!
강의를 보다보니 궁금한 점이 있어 질문 남깁니다. 첫번째로 궁금한 점은 AbstractPagingItemReader의 코드를 doRead 함수 안에서 lock을 잡고 있으며, doReadPage가 끝난 후 lock을 푸는 것을 확인할 수 있었습니다.. doReadPage에 실제로 paging 로직이 존재하니 사실상 paging 로직은 직렬로 수행되는 것과 다를 바 없을 것이며, 성능적으로 크게 증가하지 않을 것 같다는 생각이 드는데요.. (거의 직렬 처리와 유사할 것 같다는 생각이 드네요..) 사실상 병렬 처리라해도 Reader쪽에서 성능 향상이 거의 없다고 보면 될까요? 두번째로 궁금한 점은 AbstractPagingItemReader 상위 클래스인 AbstractItemCountingItemStreamItemReader의 read 함수를 보니 멤버 변수인 currentItemCount를 증가시키는 로직이 존재하더라구요.. 이 부분도 병렬처리에 문제가 될 것 같다는 생각이 들고 해당 클래스의 주석에도 "Subclasses are inherently <b>not</b> thread-safe." 라고 적혀있는 것으로 봐서는 문제가 존재하는 것 같은데요.. 그럼에도 불구하고 기능상 영향이 없으니 하위 클래스인 AbstractPagingItemReader는 thread-safe하다고 나와있는 것이라고 생각하면될까요??
안녕하신가 미스터 KILL-9 항상 빠르고 친절한 답변 고맙다 이번에 회사 로직 작성중에 조금 막막한 부분이 있어 질문 하러 왔다 reader 엑셀 파일 읽어오고 processor 에서 해당 엑셀 데이터 값을 가지고 dao 호출해서 검증하고, 깍고 (가공) 마지막으로 쓰기 처형하는데 작업을 하는데 문제는 가공 단계에서 dao 를 직접 호출하면 ExecutorType 이 simple 로 호출되고 쓰기 단계에서 batch 로 ExecutorType 실행되어 에러가 발생한다 Cannot change the ExecutorType… 이렇게 말이다.. 그래서 일단 아래 코드 처럼 해결은 했어 우선 기존 코드는 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> MyBatisBatchItemWriter -> 에러 Cannot change the ExecutorType… 해결한 코드 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> JdbcBatchItemWriter-> (해결) 그런데 이렇게 작성해도 되려나 싶네.. 그리고 String 문으로 쿼리 짜는것도 맘에 안들고..ㅠㅠ
- 명백한 한계점 (단점): - 네트워크 대역폭 소모: 실제 데이터를 전송하므로 네트워크 부하가 극심하다. 데이터 건수가 많거나 크기가 크면 통신 자체가 병목이 될 수 있다. ( "핵탄두 데이터 전송에 따른 통신망 과부하 주의!" ) - Manager 읽기 병목: Manager 혼자 모든 데이터를 읽어야 하므로, 읽기 자체가 느리다면 원격 청킹은 효과가 없다. ( "중앙 정찰 위성의 스캔 속도 한계!" ) - 복잡성(감시와 디버깅의 지옥문): 역시 미들웨어(Kafka 등)와 프링 인티그레이션 설정이 필수적이다. 프링 인티그레이션 ->스프링 인티그레이션
KILL -9 : "이 구성이 매우 중요하다. Job 설정을 보면, logFileManagerStep()이 먼저 실행되고, 그 다음에 mergeOutputFilesStep()이 실행되도록 .next() 메서드로 연결되어 있다. 없어도 뻔해서 이해되긴하는데,위의 예제에서 Job빈이랑 LogFileManagerStep빈(이건 일부러?) 빼먹은듯? KILL -9 : "이 구성이 매우 중요하다. 로 검색하면될거야 ------ 그리고 그냥 궁금한건데,이번강의챕터가 컨셉자체는 맘에드는데(코드랑 내용이랑 같이 스토리넣어서 말하는거) 인프런 강의 시스템상 너무 보기힘들지않아? 부록 2: 전장 구축 - Redis to MongoDB 데이터 이관 작전 환경 설정 같은거보면,나는 가로휠이 있어서 괜찮았는데 가로휠마우스가 없으면 마우스 드래그로 컨트롤하거나 키보드 화살표로 조금씩 밀어야하는데 이거 너무 보기 힘들거같아 스크롤바도 내용화면이 한페이지를 넘어가면 안보이고 그래서 다음거 스카이넷보고서인지 그런식으로 개행을 넣던가 하면될거같긴해 킬구<스카이넷 ? 다음거 원격 파티셔닝 강의 대부분 그냥 서두보고 다 스킵할거같은데, @ConditionalOnProperty로 조건부 빈생성 관리하는거 스킵되는거 아까운데 이거나 줏어가라고 마지막 부록에 넣어줄만하지않음? 나도 그냥 내용 대충 훑어만봤는데 저거하나는 건진거같아서
강의에서 사용되는 버전은 Spring Batch 2.5.1이고 최신 스프링 배치는 6 버전 대까지 나온걸로 알고있습니다. 그리고, 얼핏 보니 deprecated된 클래스들이 꽤 있던것같은데 (예를들면 SimpleBatchConfiguration 제거, JobBuilderFactory 제거 등), 알아보니 이제 사용자가 더 사용하기 편해졌다(?) 정도인것같습니다. 그래서 질문은 지금 이전버전의 동작방식을 이해해도, 앞으로 나오는 버전들의 동작방식은 그대로인지 아니면 다시 새롭게 배워야할 부분이 많은 지 궁금합니다!
$ kill-9.. 킬구형 추석 연휴는 잘 보냈는가.. 처음에 텍스트로만 구성된 강의인 걸 결제한 후 알게되어 당황했지만.. 걱정 마라.. 금방 킬며들었다.. 눈으로 읽고 생각하는 즐거움을 알게되었다.. 무엇보다 그동안 피로했을 내 귀를 지켜줘서 고맙다.. 아직 강의 초반이지만 궁금한 부분이 있어서 질문 올린다.. 대용량 트래픽을 다루는 회사에서는 배치 메타데이터의 양도 어마어마할 것 같은데 실무에서는 배치 메타데이터를 어떻게 관리하는 지가 궁금하다.. 혹시 배치 메타데이터를 활용할 일이 없을 것 같으면 안쌓는 것도 권장하는 방법인가..
킬구형 텍스트 강의임에도 몰입감 있는 구성에 연휴에 재밌게 공부하고 있어. 고마워 FlatFileItemWriter에 대한 흐름을 정리하고 질문 해볼게 1. sourceType() 메서드 내 객체 타입에 따라 FieldExtractor 구현체가 결정된다. 2. (Bug가 fix되기 전까지) sourceType() 메서드 내 객체 타입이 Record일 경우 names() 메서드 호출은 무시되고, Record 타입의 모든 property가 쓰일 수밖에 없다. 3. 그렇기에 Record 타입에서 필드 하나를 제외하고 파일을 쓰고싶다면, fieldExtractor() 를 사용한 커스텀 구성을 통하여 필드 하나를 제외해야 한다. 내가 강의를 보면서 정리한 흐름이고, 아래는 그 정리 중 나온 질문이야 Q1. BeanWrapperFieldExtractor 일 경우 필드 하나를 제외하고 싶다면, names() 에서 해당 필드만 제외해도 되나? Q2. 만약 위와 같은 방법이 된다면, RecordFieldExtractor 관련 Bug가 fix 된 후에 FieldExtractor를 직접 커스텀하는 경우가 별로 없지 않을까 싶은데.. 혹시 내가 생각하지 못한 부분이 있을까? 고마워 킬구형아
안녕 킬구형 형 때문에 이번 추석 연휴 재밌게 보내고 있어. 고마워 형. 강의를 보면서 예제 소스에 대한 궁금증이 생겨서 질문을 남겨. 6장. 작전4: 원격 청킹 (Remote Chunking) - 전방위적 타격이 시작되다. ☠ ' 데이터 변화 모듈(SerDes Classes)' 예제에서 예외 객체로 MessageConversionException을 사용하는데 클로드에서는 통상 Kafka를 사용할때는 org.apache.kafka.common.errors.SerializationException 을 사용해야 kafka와 호환이 된다고 하더라구. 이거에 대해 설명 부탁해도 될까?
킬구형 Spring Data JPA 사용하면 JpaRepository 인터페이스를 사용해서 PlatformTransactionManager , DataSource 를 자동으로 주입받아 사용할 수 있는데, 강의에서는 스프링배치의 세밀한 조정을 위해 일부러 JpaRepository 를 사용하지 않는 거야? 아래 두 강의에 둘 다 데이터소스와 트랜잭션매니저를 직접 활용하고 있어서 궁금해서 물어봐 3장. 작전1: 관계형 데이터베이스 읽고 쓰기 (테이블의 심장에 처형장을 세우다 ☠ ) OPERATION DOUBLE TAP - Spring Batch Test (추가) 생각해보니 예전에 아주 간단한 로직의 스프링배치 앱을 JpaRepository , JPQL을 이용해서 만들었던 만들었던 기억이 있는데,, 혹시 JpaRepository 을 일부러 사용하지 않는 이유가 있는지 궁금해
실제로 실행을 못해보는환경이라서 질문하는건데, JobLauncher를 활용한 REST API 구현 의 예제같은경우 컨트롤러 하나를 생략없이 다 표현한거같은데 jobRegistry 는 di받지않았는데 어떻게 실행하는거임? 빼먹은건가? job = jobRegistry.getJob(jobName);
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 반드시 새거만들고,상태변경시 즉시 메타데이터저장소에 저장하고) 그래도 실제 실행 따라가는 느낌이라 정리가 잘 안되는느낌이긴해서 마지막에 방점찍으면 보기 더 편할거같은느낌
