reactive

reactive

    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..

    WebFlux에서 Mono, Flux에 Map 또는 flatMap을 사용할 때 null을 리턴하는 경우

    WebFlux로 구성되어 있는 프로젝트에서 Mono, Flux stream에서 map이나 flatMap을 사용해서 특정 데이터를 매핑하는 과정에서 특정한 경우에 대해서 null을 리턴하고 다음 파이프라인에서 filter로 Objects의 nonNull을 사용해서 컨텐츠를 필터링 하려고 했다. 작성하려고 한 코드의 일부 예시를 만들어서 작성해봤다. 만약 resultData를 통해 전달받은 데이터가 예상 대로라면 map과정에서 500보다 큰 5189값만 정상 반환하고 나머지는 null을 반환한 후 filter를 통해 정상적으로 하나의 데이터만 남을 것이라고 예상했다. @Test @DisplayName("map 과정에서 반환된 null이 정상적으로 필터링 되었는지 확인하는 테스트") void mono_null..

    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버전에 문제가 있는 것을 알게 되어..

    스프링 부트와 RabbitMQ를 사용한 리액티브 마이크로 서비스

    publisher와 subscriber가 외부의 메시지 큐(RabbitMQ)와 연결되어 있는 애플리케이션을 만들어보자. Rabbitmq 설치 - 자세한 설치법은 검색을 해서 찾아보면 간단하게 나온다. - 하단의 내용은 local docker가 설치되어 있을때 docker-compose.yml을 작성할때 붙혀넣으면 된다. rabbitmq: image: rabbitmq:management ports: - "5672:5672” // 연결 포트 - "15672:15672” // 관리자 페이지 포트 (localhost:15672) Maven 의존성 추가1234 org.springframework.boot spring-boot-starter-amqpColored by Color Scriptercs Sender 클래..

    리액티브 마이크로 서비스 정리

    동일한 마이크로서비스는 서로 공유 및 통신하게 되어있다. 예를 들면 주문과 결재, 배송서비스들은 서로 공유되어있다. 이 서비스들의 호출 관계를 단순하게 동기 방식으로 호출하게 된다면 강한 의존성을 가지게 되기 때문에 마이크로 서비스의 강점을 충분하게 살릴 수 없다. 결국 모노토릭 서비스와 크게 다를게 없어진다. 그래서 도입되는 개념이 리액티브 마이크로 서비스이다. 리액티브 프로그래밍은 회복성(resilient), 응답성(responsive), 메시지 기반(message driven), 탄력성(elastic) 이렇게 4가지 기둥이 존재한다. 서로간에 마이크로서비스가 독립적으로 되어있기 때문에 특정 부분에 문제가 발생하면 해당 마이크로서비스의 복제본이 이를 대체할 수 있다. 하지만 이렇게 격리가 되었다고 해..