netty
![[카카오][세미나] Webflux로 막힘없는 프로젝트 만들기 - 정리](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FwA2QZ%2FbtrmgIkBPEd%2FtKE8KbHpjsxKnqtoYupUA1%2Fimg.png)
[카카오][세미나] Webflux로 막힘없는 프로젝트 만들기 - 정리
Spring Mvc - 하나의 요청에 하나의 쓰레드만이 사용되기 때문에 직관적 - 요청 하나의 응답이 길어지게 되면 쓰레드 하나가 계속 붙잡히고 이렇게 쓰레드들이 계속 밀리게 되면 쓰레드풀이 고갈되어 전체 시스템에 문제가 발생 Spring Webflux - 외부 시스템의 응답이 늦어져도 쓰레드가 홀딩되는 문제를 예방할 수 있다. - reactor로 개발된 코드가 circuit breaker를 연동하는데 더욱 용이하다는 장점이 있다. Reactor Meltdown - webflux는 netty의 이벤트 루프 방식을 차용한 방식으로 queue에 쌓인 이벤트를 event loop 쓰레드가 이를 처리하는 방식으로 쓰레드풀 고갈 문제를 발생하지 않음 - mvc의 기본 업무 단위는 요청 webflux는 이벤트 - ..
Spring Webflux url length 제한 413 에러 해결 방법
프로젝트에서 사용되는 특정 api에 request param의 길이가 길어지는 api가 현재 구조상 어쩔 수 없이 존재하게 되었다. 그렇게 조심스럽게 운영하다가 request param의 길이가 너무 길어져서 api에서 413에러를 내뱉으면서 결과를 반환 받지 못하는 문제가 생겼다. 우선 nginx에 있는 request param 길이 관련 설정이 문제를 유발하는지 확인해봤다. 우선 테스트를 위한 api를 하나 만들었다. 단순하게 요청을 받고 바로 반환하는 api package com.wedul.reactivetest; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annot..
Spring reactor 2.1.2 (netty 0.8.4) Mono.zip readTimeoutException 문제
Mono zip 각 Mono 처리 스레드를 병렬로 실행하고 이를 묶어서 사용할 수 있는게 Mono.zip이다. 근데 Mono zip에서 병렬로 실행되는 작업 중 하나가 empty 또는 error가 발생 되면 바로 error 또는 complete를 내뱉게 되어있다. 하지만 각 Mono 구독 작업에 error와 empty 발생 시 문제에 대해 fallback 처리를 해주면 에러가 발생하더라도 그 로직을 타게 되어있다. 하지만 2.1.2(netty 0.8.4) 버전을 사용하고 있을 때 호출 체인에서 첫 번째 요청의 실패 이후에 두 번째 요청이 정상적으로 이루어 지지 않아서 readTimeout이 발생되는 문제를 경험하였습니다. 이 문제를 해결하기 위해서 알아보던 중 2.1.2버전에 문제가 있는 것을 알게 되어..