retryCount가 전역에서 작동하는것이 좀 수상하네요. 각 메세지의 retryCount를 세어야 할 것 같은데 저렇게 두면 혹시 메세지들이 들어오면 숫자가 마구 이랬다 저랬다 할 가능성은 없나요? 이를테면 메세지 두세개가 들어왔는데 첫번째는 실패 두번째 메세지 실패 세번째 성공 이런 경우 첫번째 메세지가 성공할때까지 sync하게 작동하여 완전 처리될때까지 두번째 메세지는 아예 실행되지 않는것인가요? 아니면 평행하게 동시에 실행되는거라 저 코드가 좀 잘못된 건가요?
안녕하세요! 기존 PostRepository를 사용하다가 JPA 도입으로 JpaPostRepository가 새로 생겼는데, JpaPostRepository 클래스에 재구현을 하기 위해 default 메서드를 추가했는데 그 방법이 아닌 PostRepositoryImpl 와 같은 구현체를 만들어서 구현해도 무방할까요? 실무에서는 어떤 방식이 더 자주 사용 되는지 궁금합니다.
안녕하세요. 강의 잘 보고 있습니다. 여기서 페이지네이션 구현을 values 데이터값을 가져와서 Java단 코드내에서 stream을 사용하여 페이징 처리를 하고 있는데, 만약 데이터를 DB에서 가져온 데이터라면 쿼리에서 페이징 처리(limit, offset)를 하는게 더 효율적일까요?
형 나 지금 너무 재밌어서 잘 따라하던중 별거 아닌거에서 막혀서 좀 힘들어 형이 알려준 json 파라미터 넘기는 방법으로 해도 안되고 gpt 찾아서 진행 한거도 다 안돼는데 윈도우 환경에서 좀 힘든걸까 ?? 다른 수강생분이 올려준거도 봤는데 답변에 달아준 방법도 동작하지 않아 @Bean public JsonJobParametersConverter jobParametersConverter() { return new JsonJobParametersConverter(); } @Bean @StepScope public Tasklet terminatorTasklet( @Value("#{jobParameters['infiltrationTargets']}") String infiltrationTargets ) { return (contribution, chunkContext) -> { String[] targets = infiltrationTargets.split(","); log.info("⚡ 침투 작전 개시"); log.info("첫 번째 타겟: {} 침투 시작", targets[0]); log.info("마지막 타겟: {} 에서 집결", targets[1]); log.info("🎯 임무 전달 완료"); return RepeatStatus.FINISHED; }; }
안녕하세요! 좋은 강의 잘 듣고 있습니다. CompletableFuture.runAsync() 에 커스텀 Executor 를 따로 넘기는 코드를 보면서 궁금한 점이 생겼습니다. 동기 방식은 어차피 요청 스레드에서 직접 처리되니까 별도 스레드풀 설정이 의미 없는 거라 비동기에서만 설정하는 건가요? 아니면 동기에서도 풀을 따로 구성하는 케이스가 있는지 궁금합니다. 그리고 Java 21부터는 Executors.newVirtualThreadPerTaskExecutor() 가 기존 플랫폼 스레드풀을 대체하는 권장 방식인지도 여쭤보고 싶습니다. Virtual Thread는 풀링 없이 매 작업마다 새로 생성하는 방식이라고 이해했는데, 실무에서 전환할 때 주의할 포인트가 있다면 함께 말씀해 주시면 감사하겠습니다!
8분 29초에서 /logoutProc 를 겟방식으로 호출했고 로그아웃은 성공했습니다. 로그아웃 성공후 /logoutSuccess 로 이동해야 하고 해당 url 은 permitAll() 입니다. 그런데 왜 로그인화면이 표시되는지 궁금합니다. 강의를 조금 더 보다보니, 궁금증은 해결됐습니다. 그런데 여전히 궁금한 점은 해당 소스에 맨 아래 permitAll() 의 역할입니다. 실제 아무일도 안하는건지 궁금합니다.
안녕하세요. 잡이 어떻게 스텝에서 사용하는 컨텍스트 값까지 가지고 있는지 잘 이해가 되지 않아 질문드립니다. 분명 JobExecutionContext 에 넣은 것이 아니라 StepExecutionContext 에 값을 저장했는데, 확인해보니 JobExecutionContext 에도 동일하게 저장된 것처럼 보여서 헷갈렸습니다. 제가 이해한 바로는 JobExecutionContext 와 StepExecutionContext 는 서로 다른 영역이고, JobExecutionContext 는 step 간 공유용, StepExecutionContext 는 해당 step 전용으로 알고 있습니다. 그런데 왜 StepExecutionContext 에 넣은 값이 JobExecutionContext 에도 같은 형태로 보이는지 잘 모르겠습니다.
안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문 강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17 이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 " 레거시 다루기 " 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58 이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요? 개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 이렇게 오류가 떠서 jdk oracle을 다운 받고 sdk도 설정하고 IVM도 설정했습니다. 자바 스프링 버전은 최신 버전인 4.0.5 대신 강의 자료에서 3.x인 최신버전을 선택하라길래 3.5.13.을 선택했습니다. 무슨 문제일까요?
Orchestration SAGA 패턴 구현에 대해 고민하다가 질문이 생겨 남깁니다. 보상을 요청하는 메서드가 명시적으로 나와있어 호출할 때(동기로 호출) 만약 rollback을 요청하는 호출이 실패하게 된다면 이후의 순서대로 service에 보상 요청을 하는 동작을 멈춰야 할지 계속 진행하는 게 바람직할지 고민이 됩니다. 예를 들어 서비스 1,2,3,4가 있고 center server가 orchestration 관리를 하고 1,2,3,4 순서대로 서비스 호출해서 관리를 진행한다고 했을 때 3에서 장애가 발생해서 2를 롤백하던 중 2 롤백에서 예외가 발생해서 롤백에 실패한 경우 orchestration에서 1에 대한 롤백을 진행해줘야 할지 아니면 일단 멈춰야 할지 고민입니다. 고민의 이유는 순서대로 롤백을 해주는 것은 앞에 작업이 뒤의 작업에 의존성이 있을 때만 그렇게 해주면 되나에 대한 고민이 있었습니다. 두 롤백 간에 데이터 의존성이 없다면 괜찮지 않을까 고민했습니다. 다음으로 일단 1도 롤백을 한다면 어디서부터 어디까지 롤백이 진행됐는지 추적이 어려워지지 않을까 고민했습니다. 롤백을 어떤 것은 해주고 어떤 것은 안해준다면 어디까지 롤백했는지 추적이 힘들어지지 않을까 생각이 들었습니다.
형 ... @Bean public Step threatAnalysisStep( JpaPagingItemReader<Human> humanThreatDataReader, ItemProcessor<Human, TargetPriorityResult> threatAnalysisProcessor, FlatFileItemWriter<TargetPriorityResult> targetListWriter ) { return new StepBuilder("threatAnalysisStep") .<Human, TargetPriorityResult>chunk(10, transactionManager) .reader(humanThreatDataReader) .processor(threatAnalysisProcessor) .writer(targetListWriter) .taskExecutor(taskExecutor()) // deprecated 되어서 안씀 // .throttleLimit() .build(); } ... 에서 .throttleLimit() 부분이 5 이후로 deprecated 된다고 명시되어 있어. 관심사 분리로 인해서 taskExecutor 정의 부분에서 설정하라고 권장하는 것을 확인했거든. 현재 강의가 사실상 Spring Batch 5.x 까지의 기본 내용과 원리를 살펴봤잖아 ? 그렇다 하더라도 혼란을 줄 수 있기 때문에 해당 부분은 삭제하던지 아니면 추가 내용을 기재해야 할 것으로 보여.
학습관련 질문을 남겨주세요! 상세히 작성주시면 더 좋아요 🙂 안녕하세요, 강사님 🙂 이번 질문도 혼자 먼저 구현 후, 강사님의 강의를 들으며 리팩토링을 진행하며 궁금증이 하나 생겨 질문 드립니다. 저는 search-api 모듈의 com.library.repository의 NaverBookRepository.class 위치를 강사님과 다르게 external:naver-client 에 위치시켰습니다.(NaverBook/KakaoBook은 external 에 종속된 구현체라고 생각) 그러다 보니, naver-client 모듈이 search-api 모듈에 있는 BookRepository, PageResponse, SearchResponse 를 알아야 했으며, naver-client 모듈이 search-api 모듈을 implementation('...') 으로 의존?참조? 하게 되었습니다. // search-api 모듈 public interface BookRepository { PageResponse<SearchResponse> search(...); } 이렇게 external -> search-api 로 흘러가는 의존 방향에 이질감이 듭니다.(외부 API 가 app 을 안다..?) 그래서 모듈간 의존 방향이 search-api -> external 되도록 강사님 강의처럼 NaverBookRepository 를 search-api 모듈에 위치 시켜도 NaverClient 때문에 search-api에 feign 종속성이 생긴 다는 것이 모듈간 의존성 격리가 되지 않아서 멀티모듈의 장점이 퇴색되었다고 생각합니다. 강사님은 과제가 아닌 실무에서 search-api 와 external 간의 모듈 격리를 어떻게 하시며, 의존 방향을 어떻게 하시는지 궁금합니다. 저의 부족한 지식을 확장할 수 있게 강사님의 인사이트 공유해주시면 감사하겠습니다!