JH-Labs

이번 포스팅에서는 반응형(Reactive) 모델이 최근 떠오르고 있는 이유와 이에 대한 장단점, 반응형 프로그래밍을 표준화하기 위한 과정들, Spring에서 기존 서블릿을 대체하는 반응형 네트워크 엔진 등에 대해 알아본다. Blocking I/O와 Non-Blocking I/O의 동작 원리 반응형(Reactive) 프로그래밍을 이해하기 위해선 Non-Blocking I/O의 동작 원리와 Blocking I/O와 비교했을 때 어떤 장단점이 있는지를 명확하게 이해해야 한다. 위 그림과 같이 Non-Blokcing I/O 모델은 I/O가 발생하더라도 block되지 않기 때문에 다른 요청을 처리할 수 있게 된다. 따라서 더 적은 양의 쓰레드와 CPU로 다수의 요청을 동시에(Parallel의 의미가 아니라 Con..

스프링 프레임워크와 스프링 부트의 차이점 중 하나는 AutoConfiguration의 기능으로 알고 있었지만, 이 기능이 어떤 방식으로 동작하는지 궁금했고 이번 기회에 스프링 부트의 AutoConfiguration의 동작 과정에 대해 포스팅해보았다. 본론으로 들어가기 앞서 Spring과 Spring Boot의 차이점에 대해 알아보자. Spring과 Spring Boot의 가장 큰 차이점은 '의존성의 버전 관리'와 '간편한 자동 설정'이다. Spring - 필요한 dependency를 모두 직접 빌드 툴에 등록해줘야 한다. - Dependency의 버전을 직접 명시해줘야 한다. - 필요한 설정 파일을 작성하고 빈으로 등록해야 한다. Spring Boot - 필요한 dependency의 묶음을 제공하고 추가..

기본적으로 톰캣은 쓰레드 풀에 200개의 쓰레드를 두고 요청 당 할당한다고 알고 있었지만 여기서 의문점이 생겼다. 그렇다면 동시에 최대 200개의 요청만 처리할 수 있는 것일까? 이번을 기회로 지금까지 스프링 부트 개발을 하면서 사용해왔던 톰캣의 기능과 톰캣이 요청을 받아 서블릿 컨테이너로 위임하는 과정 / 톰캣의 I/O 방식을 주제로 작성했다. Tomcat이란? 톰캣은 아파치 재단에서 관리되며 Java 표준 인터페이스인 서블릿을 지원하기 위한 미들웨어이다. 톰캣은 OS로부터 네트워크 요청 정보를 받아와 자바 객체로 만들고 이를 서블릿 컨테이너로 위임한다. 톰캣은 웹 애플리케이션의 다양한 스펙 사항(서블릿 스펙, JSP스펙, '웹소켓' 스펙 등)을 준수하며 개발되었다. 링크(https://tomcat.a..

아파치 Tomcat의 BIO Connector / NIO Connector 개념 1) BIO Connector - Response를 보내고 끝내는 것이 아니라 TCP Connection이 만료될 때까지 Thread가 활성 상태로 남아있으며 소켓이 닫히면 Pool로 반환되는 구조 - Connection이 만료되기 전까지 Thread가 활성상태로 남아 있기 때문에 Idle Thread 발생 - '최대 동시접속 클라이언트 수'와 '쓰레드 풀의 쓰레드 수'가 같음 2) NIO Connector - Java의 I/O 라이브러리인 NIO를 활용하여 Tomcat에서 만들어진 Connector - Poller라는 단일 쓰레드가 Selector를 이용하여 처리가 가능한 순간에만 Thread를 활성화시킴으로써 Idle T..

최근 MockMvc 기반으로 컨트롤러 단의 테스트 코드를 작성하다가 핸들러가 호출되지 않는 문제를 마주했고 이를 해결하기 위해 컨트롤러까지 요청이 들어오기까지 어떤 과정을 거치는지 알아야 할 필요성을 느껴 포스팅을 준비했다. 서블릿이란 과거에는 거의 동적인 컨텐츠만 다루는 웹 시스템이었으나 동적인 컨텐츠를 다루면서 웹 서버에 프로그램을 붙여 동적인 페이지를 제공하도록 변화했다. 그래서 등장한 것이 서블릿과 WAS이고 서블릿은 자바 Interface로 정의된 명세사항(specification)이다. (servlet은 javax 패키지에 정의된, 자바에서 정의한 스펙 사항이며 다른 플랫폼에서는 사용되지 않는다) 서블릿의 스펙사항을 기반으로 만들어진, 서블릿을 관리하는 서블릿 컨테이너가 WAS에서 구동된다. ..

모델 단을 단위 테스트하는 것과 비슷하게, 컨트롤러도 Mockito와 Junit을 이용해 단위 테스트할 수 있다. 하지만 이 경우 실질적인 HTTP 제이슨 페이로드를 받아 검증하는 방식은 아니다. @Vaild와 같은 어노테이션을 포함한 다양한 것들을 검증하기 위해서는 Mockito와 Junit 만으로는 부족하다. 이러한 경우를 대비해 스프링이 MockMvc를 제공하고 이를 활용해 컨트롤러 end point를 적용한 테스트를 진행할 수 있다. 즉, MockMvc를 활용하면 모의 서블릿 환경에 대한 테스트를 작성할 수 있다. 또한 Mockito에서 제공하는 @Mock이나 @InjectMocks와 같은 어노테이션은 스프링 컨텍스트에 로드하지 않기 때문에 컨트롤러 테스트에서는 사용될 수 없다. 이때는 @Mock..

영속성 전이와 고아 객체는 다른 개념이다. CascadeType과 orphanRemoval은 각각 영속성 전이와 고아 객체 개념에 해당한다. 1. CascadeType.REMOVE - 부모 엔티티가 삭제될 때, 자식 엔티티도 함께 삭제되도록 한다. - 부모 엔티티에 설정한다. 따라서 양방향 연관관계일 경우에만 해당한다. - 부모를 삭제하는 것이 아닌 단순히 부모와 자식의 연관관계를 제거하는 연산에 대해서는 자식 엔티티를 삭제하지 않는다. 예를 들어 부모 엔티티에서 one-to-many로 Collection 형태의 자식 엔티티들을 가지고 있을 때, 해당 Collection에서 특정 자식 엔티티를 삭제하는 연산에 대해서는 delete 쿼리가 발생하지 않는다. 부모 엔티티가 삭제된 것이 아니기 때문이다. cf..

양방향 연관관계 - 일반적으로 RDB는 방향이 존재하지 않음. 즉, 양방향이라는 개념 자체가 없음 - OneToMany를 사용하더라도 실질적으로 One 쪽의 DB에 컬럼이 생기지 않음 - 객체 단에서 편리함을 제공하기 위해 양방향 연관관계를 제공하는 것 - 따라서 JPA에서 양방향 연관관계를 사용할 경우 연관관계 주인을 정의해 줘야 함 - 연관관계의 주인인 Entity만 외래키의 값을 변경할 수 있고 상대방 Entity는 조회만 가능한 제약이 있음 - 양방향 연관관계를 설정하면 양쪽 모두에 참조 변수를 설정해 줘야 함(동기화 필요). - 이러한 불편함을 해결하고자 연관관계 편의메소드를 활용 - 일반적으로 연관관계 편의 메소드는 주인 엔티티에 정의함(주인이 아닌 쪽에 정의해도 됨) - 추후 유지보수나 확장..