☠ 질문 가이드 ☠ " 시스템 종결자의 지령이다. 질문하기 전에 이 규칙들을 숙지하도록. " 1. 코드 실행에 문제가 있다고? 전체 코드를 보여줘라. 단편적인 에러 메시지만으로는 아무것도 알 수 없다. 실행 환경도 알려달라. JDK 버전, 스프링 버전 등을 함께. 2. 오타를 발견했나? 즉시 제보하도록. 자네같은 날카로운 눈을 가진 동료가 필요하다. StepExecution stepExecution = contribution.getStepExecution(); ExecutionContext stepExecutionContext = stepExecution.getExecutionContext(); Integer infiltrationCount = (Integer) stepContext.get("infiltrationCount"); JobExecution jobExecution = stepExecution.getJobExecution(); jobExecution.getExecutionContext().put("totalInfiltrations", infiltrationCount); 혹시 stepExecutionContext가 stepContext인데 이름이 오타가 난게 맞는지?? 7강 자료에서 찾은것이다. 3. 질문은 자유롭게 "이런 걸 물어봐도 될까요?" 같은 소심한 멘트는 불필요하다. 궁금한 건 바로 물어봐라. 배치 시스템에 소심한 건 없다. 4. 검색은 기본 비슷한 질문이 있는지 먼저 확인하도록. 하지만 이해가 안 된다면? 주저하지 말고 추가 질문해라. GPT가 거짓말친다고? 나에게로 오라. 💀 5. 서로 존중하라 여기는 모두가 시스템을 지배하고자 하는 동료들이다. 서로를 이해하고 돕는 문화를 만들어가자. ⛔ 인프런 서비스 자체에 대한 문의는 1:1 문의하기로. 💀 그쪽 서버는 막강한 CTO가 있어 건드리지 않는 게 좋을 거다 💀 - KILL-9 올림 P.S. 존댓말로 질문하면 rm -rf를 시전한다. 편하게 물어보도록. 강의에서 놓친 부분이나 더 보충하면 좋을 내용도 자유롭게 제보하라. 너희의 피드백이 이 강의를 더 강력하게 만든다. 🔥 시스템을 함께 진화시켜 나가자. 🔥
외부 API를 호출해서 DB에 적재하는 배치를 구성을 하려고한다. 이때까지 문서 내용을 바탕으로는 Chunk가 아닌 Tasklet으로 해도 문제가 없다고 판단이든다. 하지만 공공 데이터 API를 1번 호출 할 때 10건씩만 데이터를 조회해야한다는 단점이있다. 평소에 하루에 1번 호출하겠지만 지난 3달의 데이터를 일단 적재를 해야한다. 이런 상황에서도 RepeatStatus.CONTINUABLE 이 아닌 while문으로 계속 호출하고 끝나면 RepeatStatus.FINISHED 로 반환해도 되는 지 궁금하다. 또한 외부API를 호출 할 때 PageNo도 명시를해줘야하는데 pageNo을 1씩 증가시키다가 특정 pageNo일때 오류가나면 해당 pageNo일때 부터 동작하도록 하려면 Jenkins의 매개변수 값을 설정해서 다시 batch를 돌리려고한다. 하지만 아래처럼 PAGE_NO을 정수로하고싶었는데 String으로 해야한다는 점이있어, 리스너에서 해당 매개변수를 Integer 또는 Long 타입으로 변경을 해야하는 과정을 추가해야 할 지 아니면 더 수월한 방법이 있는 지 궁금하다. 💀 [시스템 인텔리전스] 일반적으로 Tasklet에서 DB 트랜잭션 관리가 필요한 않은 경우가 많지는 않다. 모든 Tasklet이 데이터베이스 작업을 포함하는 것은 아니기 때문이다. 예를 들어, 파일을 정리하거나, 외부 API를 호출하거나, 단순한 알림을 보내는 작업이라면 DB트랜잭션을 고려할 필요가 없다. 그러므로 반복이 필요할 경우 작업의 성격을 잘 판단해서 while문으로 처리할지, RepeatStatus로 처리할지 현명하게 선택하라. 모든 반복을 RepeatStatus로 처리하는 것이 능사는 아니다.
이전 청크의 ItemProcessor에서 엔티티를 수정한게 왜 문제인지 이해가 안간다. ItemProcessor에서 데이터를 수정하고 ItemWriter에서 DB에 flush를 할것 같은데 왜 다음 chunk에서 ItemReader에서 doReadPage()로 데이터를 읽는 시점에 의도치 않게 DB에 변경사항이 발생하는가?? 이미 앞선 데이터는 DB에 모두 반영되지 않았는가?? 이전 청크라는 상황이 이해 안된다. 이것이 왜 위험한가? 만약 이전 청크의 ItemProcessor에서 엔티티를 수정했다면? doReadPage()에서 데이터를 읽으려는 시점에 의도치 않게 DB에 변경사항이 반영될 수 있다. 이는 ItemReader의 책임 범위를 완전히 벗어난 동작이다. ItemReader는 데이터를 읽기만 해야 하는데, 실제로는 데이터 변경까지 일으킬 수 있는 것이다. 더 큰 문제는 이런 동작을 코드를 자세히 들여다보지 않으면 전혀 예상할 수 없다는 점이다.
배치 처리, 시스템 종결의 서막 💀 장에서 중복된 문장 발견. 두 세계의 공존 웹은 실시간 상호작용의 최전선에서 사용자와 연결을 담당한다. 배치는 시스템의 후방에서 대규모 데이터 처리를 책임진다. 둘은 역할이 다르지만, 함께 작동할 때 시스템은 완벽해진다. 함께 작동할 때 시스템은 완벽해진다. 배치가 없다면 시스템의 무게를 견딜 수 없고, 웹이 없다면 사용자와의 연결이 끊어진다. 네가 이 두 세계를 모두 이해하고 다룰 수 있다면, 시스템의 모든 것을 지배할 수 있다.
안녕하세요! 현재 자연어 기반 AI 장소 추천 & 실시간 예약 시스템 을 취업 포트폴리오 프로젝트로 개발 중입니다. 네이버 지도 API를 활용해 평점과 리뷰, 예약 가능 여부 등을 기준으로 장소를 추천하려고 합니다. 문제는 실제 예약과 리뷰는 네이버 외부에서 이루어지다 보니 , 실제 예약 가능 시간대와 사용자가 정말 예약했는지 여부를 알 수 없고, 그에 따라 내부 DB에 히스토리를 남기기도 어려운 상황 입니다. 그래서 고민 중인 부분은 실제 장소는 보여주되, 임의로 예약 가능시간대를 만들어 사용자가, 내부 DB에 예약 및 작성한 리뷰 히스토리를 저장하는 방식 으로 가짜 히스토리를 남기는 것이 현실적인지에 대한 것입니다. 임의로 가짜 예약 시스템을 만들자니 포트폴리오 질이 조금 떨어지지 않나 하는 고민이 커서 현재 막힌 상태입니다.. 혹시 저처럼 네이버 API 기반으로 구현하셨던 분들 중에 이런 상황에서 예약/리뷰 기록을 어떻게 처리하셨는지 , 또는 위 방식이 괜찮은 설계인지 조언을 부탁드립니다! 읽어주셔서 감사합니다!
아래 설명에서 실무에서 어쩔 수 없이 실시간으로 변경된 데이터셋에 배치 처리를 한 사례를 알고싶다. "잠깐! 킬구형, JpaPagingItemReader의 문제가 아니라 실시간 데이터셋에 배치를 돌리는게 잘못된거 아냐?” 이상적으로는 맞는 말이다. 배치는 보통고정된 입력 데이터셋을 대상 으로 사용하는 것이 맞다. 하지만 실무에서는 어쩔 수 없이 실시간으로 변경되는 데이터셋에 대해서도 배치 처리를 해줘야 할 때가 있다. 이럴 때는 offset 기반 페이징 은 사용하지 않도록 하자.
같은 요청이 여러 번 들어와도 한 번만 처리하는 것. 여러 번의 요청이 들어왔을 때 이 요청이 '같은 요청' 이라는 것을 정확하게 판단할 수가 있을까요? 예를 들어 똑같은 점포의 똑같은 POS에서 똑같은 액수의 포인트 적립/사용이 두 번 들어왔을 때, 이 두 요청이 각자 다른 요청인지? 클라이언트 단의 문제로 인해 같은 요청을 두 번 보낸 것인지? 정확하게 판단할 수 있는 걸까요? 두 요청의 도착 시간 간격이 매우 짧을 때 -> 일반적인 상황에서 같은 동작이라고 판단할 수야 있겠지만.. 매우 빠르게 요청을 계속해서 받아야 하는 상황이라면? 도메인 특성에 따라 같은 요청임을 판단할 수 있는 기준이나 상황이 달라지기야 하겠지만 정확하게 보장 받을 수 있는 기준은 존재하기 어렵지 않나 하는 생각이 듭니다. 실제 사례를 통해 예시를 들어주실 수 있는 게 있을까요?
킬구형 안녕, Fault Tolerant 쪽에서, retryLimit()을 설명해줄 때 만약 retryLimit 값이 3일경우, "첫번째 호출시도 1번, 재시도 호출 2번"으로 총 3번이 호출된다고 했잖아. 재시도 횟수는 항상 retryLimit - 1 이라 그랬고. 근데 왜 "ItemProcessor의 예외 발생 시 재시도 - 아이템 단위로 재시도 관리"의 마지막 호출 결과 찍어준 부분에서, retryLimit()은 3인데 왜 ItemProcessor는 4번이 호출되는거야? 위에 설명한대로라면 3번만 호출되어야 하는거 아냐?
안녕하세요. 테스트코드 작성 중 아래 파싱하는 부분 관련하여, as Byte -> toInt 변환 도중 에러가 발생합니다.. DB스키마 DDL의 경우, boolean -> tinyint(1) 로 생성된것으로 보이는데, 어떻게 해결할 수 있을까요? ``` class java.lang.Boolean cannot be cast to class java.lang.Byte (java.lang.Boolean and java.lang.Byte are in module java.base of loader 'bootstrap') java.lang.ClassCastException: class java.lang.Boolean cannot be cast to class java.lang.Byte (java.lang.Boolean and java.lang.Byte are in module java.base of loader 'bootstrap') ``` isPaymentDone = ((results.first()["is_payment_done"] as Byte).toInt()== 1),
멀티 스레딩에서 파일에 write할 때 질문이 있습니다. thread가 chunk 단위로 파일에 입력되는것은 확인했습니다. 그런데 결과 값의 정렬은 불가능한가요???? 예를 들어 db에 1, 2, 3, 4, 5 ... 라는 데이터가 있고 FlatFileItemWriter로 파일에 쓸 경우 1,2,3,4,5 이런식으로 정렬된 값이 저장 가능한지
humanThreatDataReader는 스레드 안전한 JpaPagingItemReader 를 사용했다. 라는 구문에서 헷갈리는게 있는데 JpaPagingItemReader의 경우는 lock을 걸지 않는데 SynchronizedItemStreamReader 데코레이터를 적용해야하지 않나요???
상태(State): 작전 수행 지점들 상태(State)란 Flow 내에서 현재 실행이 머무르거나 도달할 수 있는 모든 논리적 지점 을 의미한다. 자동문의 "문 닫힘/문 열림" 에 해당한다. Flow를 구성하는 상태(State)는 크게 두 가지 주요 유형으로 분류할 수 있다. 실행 상태 (StepState 등): 실행 상태는 Flow 내에서 실제 특정 작업(로직)을 수행하는 지점을 나타낸다. 우리 강의의 예제 코드에서 사용된 analyzeContentStep , publishLectureStep , summarizeFailureStep 과 같은 Step이 대표적인 실행 상태(StepState)에 해당한다. 종료 상태 ( EndState ): 종료 상태는 Flow 실행의 최종 도착점을 나타내는 상태이다. Flow가 이 상태에 도달하면 더 이상 진행되지 않고 실행이 종료된다. Job의 최종 결과는 Flow가 어떤 EndState 로 끝났는지에 따라 결정된다. 다이어그램의 [작업 종료] 가 바로 이 종료 상태(EndState)를 가리킨다. 종료 상태(EndState): Flow 실행의 최종 도착점 이다. 이 상태에 도달하면 실행 흐름이 더 이상 진행되지 않고 Flow가 종료된다. Job의 최종 결과는 어떤 EndState로 끝났는지 에 따라 결정되며, 앞선 다이어그램의 [작업 종료] 가 바로 이 종료 상태(EndState)에 해당한다. 여기서 종료 상태가 두개인데 다른 내용인가요???
이 기본 구현에서 호출하는 getResultList() 는 전체 데이터를 메모리에 한 번에 로딩하므로 실제 스트리밍이 아니며 따라서 타 JPA 구현체 사용 시 주의가 필요하다. 라고 하셨는데 JpaCursorItemReader를 이용하면 모든 데이터를 메모리로 가져오기 때문에 OutOfMemoryError가 날 수 있나요?? 추가로 실무에서는 쿼리가 복잡할텐데 JPA 보단 JDBC를 사용하는 편인가요???
