이번 포스팅에서는 Reactor pattern 에 대해 알아보겠다. reactor pattern 의 목표 한정된 스레드로 동시에 들어오는 요청을 효율적으로 처리 가능 Reactor 패턴 대표 사용 기술 Java NIO, Selector, epoll 특징 Selector 기반의 Java NIO 를 사용하기 때문에 동기 non-blocking 으로 동작한다. (IO 관점) 작동 방식 accept, read, write 등의 이벤트(준비 완료)들을 한 곳(Selector)에 등록하여 모니터링 -> Selector 사용, Multiplexing 준비 완료 이벤트(처리될 준비가 됨)일 경우에는 request handler 에게 전달한다. -> Demultiplexing 대표 컴포넌트 Reactor 별도의 스레드에..

Java AIO (NIO2) 에 대해 알아보겠다. 참고라이브러리가 따로 있는건 아니고..java.nio 를 공유하며..대신 사용되는 클래스이름이..앞에 "Asynchronous" 가 붙는다.예시 ) AsynchronousServerSocketChannel 이전 상황Java NIO, Selector, epoll(커널) 을 쓰게되면...커널에서 애플리케이션으로 accept, read 등의 준비 완료 이벤트를 전달해주지 않고애플리케이션에서 커널로 직접 주기적 확인이 필요했다.즉.. busy-wait 가 발생하고 있는 것이다. (동기 non-blocking) Java AIO 에서는 이를 해결한다.  Java AIO 동작커널의 역할I/O 작업이 커널에 전달되고, 커널은 이 작업을 비동기적으로 처리한다.작업이 완료..

이전 포스팅에서 selector 를 알아봤는데... 결국 selector 는... 여러 이벤트를 하나의 스레드로 한꺼번에 확인할 수 있는 객체였다. (IO Multiplexing) 그러면 다시 busy-wait 관점에서 생각하자면.. selector 가 도입 되면서.. busy-wait 가 사라졌을까.. 아니다.. 사용자 코드에서는 사라졌지만, selector 가 사용자를 대신해서 준비 완료되었는지.. 확인하고 있는 것이다. 혹은... selector 로 좀더 편하게 준비 완료되었는지 확인하는 것이다.. 좀더 설명하자면.. selector 사용 전에는 accept, read (IO 호출)를 직접 호출(사용자 코드가 Caller 입장)하였지만.. 이제는 사용자 코드가 Callee 느낌으로.. selecto..

이전 포스팅에서 Java NIO 를 사용할 때 Java NIO 가 동기 non-blocking 방식이라 busy-wait 이 발생하였다. busy-wait 에 대해 잠시 복습하고 진행하겠다. busy-wait 은 동기 non-blocking 구조에서 자주 보이는 현상으로.. non-blocking 이라 caller 는 callee 작업으로 부터 자유로운데 동기 방식이라 callee 의 작업이 끝났는지(결과를 받을 수 있는지) 주기적 확인이 필요한 상황이다. 그래서.. 주기를 늘리면 실시간성이 떨어지게 되고.. 주기를 좁히면 그만큼 blocking 과 다를 바가 없고 CPU 자원이 낭비 되는 것이다. 문제는 서버에서는 여러 이벤트를 동시에 다루고 여러 요청을 다룰 수 있어야한다. 위와 같은 방식에서는 ac..

Java NIO (new IO) 를 이용한 Server - Client 의 동작을 동기 / 비동기, blocking / non-blocking 관점에서 알아보겠다. 참고로 java.nio 패키지에 존재하는 selector 는 다음 포스팅에서 다루겠다. Java IO 와 다르게 Java NIO 는 non-blocking 하게 동작할 수 있는 옵션이 존재한다. -> ServerSocketChannel::configureBlocking 메서드를 호출해주고 파라미터 값으로 false 를 전달한다. 해당 옵션을 사용하면, accept 와 read 에서 blocking 되지 않고 바로 넘어간다. 각각 null, 0 을 리턴해버린다. accept 의 예시 코드를 보며 계속 하겠다. 즉, non-blocking mod..

이번 포스팅에서는 Java IO 를 이용한 Server - Client 의 동작에서 동기 / 비동기, blocking / non-blocking 관점과 CPU 자원 소모를 알아보겠다. server side accept 서버를 구동하면 blocking 되는 첫번째 포인트이다. 클라이언트에서 연결 요청이 올때까지 blocking 된다. read 클라이언트에서 요청 데이터를 보내서 서버 버퍼에 도착할 때까지 blocking 된다. write 서버에서 클라이언트로 보낼 응답 데이터를 서버 OS 네트워크 버퍼에 적재를 완료할 때까지 blocking 된다. -> accept, read 와 다르게 클라이언트의 시그널을 기다리는 것은 아니다. client side connect 클라이언트가 서버에 연결될 때까지 blo..

이번 포스팅 주제는 개인적으로 생각하는 Spring 의 철학입니다. 들어가기 앞서 SOLID 원칙에 대해 살짝 알아보고 가봅시다. SRP (Single Responsibility Principle)단일 책임 원칙입니다. 하나의 클래스는 하나의 책임만 가져야 한다. 다른 말로는 클래스가 변경되는 이유는 한가지여야 한다 입니다. OCP (Open / Close Principle)개방 폐쇄 원칙입니다. 풀어서 보면, 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 입니다. 좀더 쉽게 보자면, 확장에는 열려있다. -> 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다. 수정에 닫혀있다. -> 기존의 소스 코드를 수정하지 않아도 모듈의 기능을 ..

본격적으로 Reactive Stream 에 대해 알아보겠다. (by java.util.concurrent.Flow) Publisher Reactive Stream 의 Publisher 이다. - publisher 는 데이터 혹은 이벤트(메시지)를 제공한다. subscribe - publisher 에 subscriber 를 등록할 수 있다. (다수를 등록할 수 도 있다.) Subscriber Reactive Stream 의 Subscriber 이다. Subscriber 는 Publisher 로 부터 다양한 이벤트가 들어오는 채널을 구현해야한다. 참고 publisher 에서 subscriber 에게 데이터 혹은 이벤트를 전달하는 방식은 push 방식이다. onSubscribe - publisher 에서 호출..