TL;DR 프록시 기능을 사용할 수 없기 때문에 프로퍼티에 final을 붙이면 안됩니다. val이냐 var이냐 상관없이 프록시 기능은 작동합니다. 필드 접근 방식이 아닌 프로퍼티 접근 방식이면 val을 쓸 수 없습니다. 필드 접근 방식인 경우 아래 결론으로 이어집니다.

Kotlin 환경에서 JPA를 사용하려면 Java와 다르게 추가 설정이 필요하고 염두에 두어야 할 주의사항이 있습니다. All-open 플러그인 설정 No-arg 플러그인 설정 val vs var, final vs open equals & hashCode data class 써도 되는지 Sparing 사용하지 않는 경우 Gradle에서 Entity 스캔 경로 설정 트릭 All-open 플러그인 설정 JPA의 엔티티에 @~ToMany 어노테이션을 사용할 경우 기본으로 설정되는 lazy loading 기능은 사용자가 만든 클래스를 상속한 프록시 객체를 이용해 구현합니다.

gRPC는 기본적으로 HTTP/2 위에서 동작하는 프로토콜입니다. 그런데 Armeria가 가진 장점 중 하나로 gRPC를 HTTP/1.1 환경에서 gRPC를 사용할 수 있습니다. 비슷한 장점으로 HTTP/1.1 위에서 동작하는 Thrift를 HTTP/2 환경에서 서비스할 수 있습니다. Armeria는 어떻게 이런 유연한 통신 방식을 사용할 수 있을까요?

우리에게 익숙한 Tomcat 기반의 Spring Web MVC 서버는 멀티쓰레딩 방식으로 요청이 들어오면 이를 전담하는 쓰레드를 생성하여 처리합니다. 따라서 특별히 별도의 쓰레드를 생성하지 않는 한 하나의 쓰레드가 모든 작업을 실행합니다. 반면 Armeria와 같은 멀티플렉싱 방식은 하나의 요청이 여러 쓰레드를 거쳐 처리될 수 있습니다.

TL;DR Hooks.onOperatorDebug() 메소드를 애플리케이션 시작 시 실행하기 Publisher assembly 도중에 checkpoint() 연산자를 사용하기 log() 연산자로 이벤트 로깅하기 Reactor 공식 문서를 참고하여 위 방법 중 하나를 이용하면 됩니다. 전체 애플리케이션 범위를 디버깅할 때는 1번, 범위를 좁혀서 관심있는 Publisher만 디버깅할 때는 2번, Publisher의 이벤트를 로깅하고 싶다면 3번을 사용합니다.