컨트롤러 호출 안되는 이유 질문

시간이 좀 지난 질문이지만, 다른 분들도 궁금하실 것 같애서 추가 답변 남깁니다.@ModelAttribute 를 사용할 경우 ModelAttributeMethodProcessor(ArgumentResolver)가 사용됩니다.여기서 리플렉션을 통해 @ModelAttribute 객체의 생성자를 기본 생성자를 호출합니다.(모든 필드 변수의 값이 디폴트 값[int = 0, String = null, ...])이후 DataBinder 를 사용하여 요청 파라미터의 key를 가지고 리플렉션을 통해 @ModelAttribute 객체의 같은 key 에 대한 정보를 찾습니다.그리고 찾은 필드 변수의 타입을 가지고 요청 파라미터의 값을 설정합니다.이 때, int 필드에 문자열이 들어가면 형 변환에 실패하고, BindingResult 에 FieldError 를 넣는 과정이 있습니다.그래서 @ModelAttribute 경우 TypeMismatch 에러가 발생해도 BindingResult 를 파라미터러 받는다면 컨트롤러가 호출됩니다. @RequestBody 의 경우는 RequestResponseBodyMethodProcessor(ArgumentResolver)가 호출됩니다.이후 AbstractJackson2HttpMessageConverter(HttpMessageConverter)에서 Jackson 라이브러리를 통해 요청 HTTP 메시지 바디의 json string 를 @RequestBody 객체로 변환하는 작업을 합니다.이 때, int 필드에 문자열이 들어갔다면, Jackson 라이브러리에서 InvalidFormatException 을 발생시키고, BindingResult 가 있더라도 컨트롤러에 진입 조차 할 수 없고 400 예외 메시지가 발생하게 됩니다.이 차이 떄문에 @ModelAttribute 는 클라이언트가 잘못된 데이터 타입의 값을 입력해도 적절한 에러 메시지를 바인딩하여 컨트롤러에 진입할 수 있지만, @RequestBody 는 아예 컨트롤러 진입 전에 요청이 실패하는 차이가 있습니다. 감사합니다.`

ItemReader에서 chunkSize의 두 사용 방법 비교

지나가는 학생입니다.상황 1의 경우 스프링 배치에서 제공하는 ItemReader에는 없을 것 같군요.굳이 구현한다면 ItemReader 인터페이스를 직접 구현해서 사용할텐데, 해당 구현 내용에는 select * from table limit 1 offset 0...2000 이렇게 증가하면서 조회한다고 가정하겠습니다. 상황 1과 상황 2의 성능을 비교한다면,차라리 상황 1이 더 더 빠르다고 생각되네요.어차피 상황 1과 2 둘다 커넥션 풀에 있는 커넥션을 사용할거라 커넥션 생성 비용은 동일할텐고요.다만, 상황 2에서는 chunk size 단위로 커밋이 이뤄지기 때문에 커밋(네트워크 통신) 2000번이 발생하겠네요.상황 1에서는 write 커밋은 1번할테니 둘의 커밋 차이는 2000배가 되겠네요. 도움이 되셨기를~

KStream, KTable 조인 스트림즈 애플리케이션에서 에러가 발생하고 있습니다.

자답입니다.m1 칩을 사용할 때 kafka-streams 라이브러리의 rocksDB 버전이 6.29.4.1 이상이여야 정상 동작합니다.https://github.com/facebook/rocksdb/issues/7720(사진)kafka-streams 2.5.0 + rocksDB 6.29.4.1을 사용할 경우 2개의 버전이 호환이 되지 않아 에러가 발생합니다.정상적으로 사용하기 위해서 implementation 'org.apache.kafka:kafka-streams:3.2.0' 이상의 버전을 사용하시면 됩니다.

POST를 사용한 회원 삭제

http method는 단순히 스펙일 뿐이지 사실 delete에서 데이터를 생성하는 로직을 만들수 있습니다.당연히 post에서도 데이터를 삭제할 수 있고요.기본적으로는 uri와 httpmethod만 보고 이 api는 사용자를 생성 하구나~ 이렇게 식별할 수 있게 만드는 것이 좋은 api 설계입니다.질문자님이 얘기하신 delete를 사용한다고 알아서 삭제해주는 것이 아니라 delete를 호출했을 때 실행되는 메서드에서 삭제하는 로직을 직접 작성하셔야 합니다.post를 호출했을 때 동작하는 것은 post uri에 해당되는 메서드를 호출하는게 전부입니다. post를 호출했다고 알아서 해주는건 없습니다~

test DB 설정 질문

지나가다 들린 학생입니다. 스프링은 기본 원칙은 더 "자세한 설정을 사용한다" 입니다. properties에 설정된 설정보단 직접 @Bean을 사용한 설정이 더 우선 순위를 갖게 되어 사용되는게 맞습니다.

레거시 코드에서 DriverManager를 사용하는데요...

강의를 듣는 학생입니다. 커넥션을 1개로 계속 사용하면 커넥션 풀에 1개인 것과 비슷하다고 볼 수 있네요. 다만 커넥션을 일정 시간 사용하지 않으면 커넥션 타임 아웃이 발생하겠네요. 개인적으로 커넥션을 1개로 돌리면 배치에서 작업하는 특성에 따라 다를 수 있을 것 같네요. 예를 들어 중복 체크하는 로직이 들어가 있어야 하는데 커넥션을 1개로 돌린다면 빠져도 될 수 있겠어요. 커넥션을 맺는 작업은 맺는 당시에만 비용이 발생하니 비용이 비싸서 1개를 사용하는 것 같진 않네요. 다른 숨은 의도가 있을 수도 있을 것 같네요. 보통 배치가 오래걸리면 그 시간 만큼 서비스에서 배치 결과를 늦게 보여주는 거니 저라면 커넥션을 늘리고 멀티 쓰레드를 사용하여 배치를 돌려 작업 시간을 줄일 것 같네요. 동시 처리 작업이 5개라고 하니 최소 5개는 사용할 것 같고요. 제 답변이 도움될진 모르갰지만 지나가다 적어봅니다. 선생님 답변도 기다려보겠습니다~

RDS 보안 그룹 설정을 위한 인바운드 규칙 편집에서 아래와 같은 에러가 납니다

저도 동일한 증상이 나타납니다. (사진) (사진)