fn(Rice) -> Code

Vert.x 실행 할 때 Verticle 개수와 CPU 개수나 Thread 개수 연관 등이 궁금해서 잠시 테스트 해 보았다. Vert.x의 Verticle은 Event Loop에서 동작한다. 여기서 Event Loop는 Netty의 "io.netty.channel.nio.NioEventLoop"를 말하며, NIO Selector 기반이다. NIO Selector 설명   간단한 EventLoop 구현 NioEventLoop.java Event Loop Pool 개수는 NioEventLoop를 생성하는 개수가 된다. Event Loop Pool 개수를 지정 하지 않으면 아래가 기본 공식이다. 2 * Runtime.getRuntime().availableProcessors() Vert.x의 Verticle은 Event Loop에서 동작한다 했다. 정확히는 Event Loop는 Single Threaded Executor이고 Verticle은 하나의 실행 Task이다. Verticle이 실행 될 때 Thread 이름과 함께 로그를 남겨 보면 Verticle을 실행한 Event Loop의 Thread를 확인 할 수 있다. [ vert.x-eventloop-thread-0 ] INFO fs.App - !!!Start App!!! [ vert.x-eventloop-thread-1 ] INFO fs.redis.Redis - !!!Start Redis!!! [ vert.x-eventloop-thread-2 ] INFO fs.redis.Redis - !!!Start Redis!!! [ vert.x-eventloop-thread-3 ] INFO fs.web.Http - !!!Start Http!!! [ vert.x-eventloop-thread-4 ] INFO fs.web.Http - !!

 카프카 프로듀서는 메시지를 전송할 때 ByteBuffer를 사용한다. ByteBuffer는 생성하는 쓰레드에서 큰 메모리 단위를 생성하거나 여러 버퍼에 할당된 메모리를 해제할 때 쓰레드는 기아가 되거나 데드락이 될 수 있다. 이런 문제 때문에 프로듀서는 BufferPool을 사용한다.  이 BufferPool은 충분한 메모리가 확보 될 때 까지 쓰레드를 기다리게 할 수 있고, 이미 생성된 ByteBuffer를 재사용 할 수 있으며, 제한된 메모리로 동작할 수 있게 한다. 실제 BufferPool.java 는 메트릭 관련 코드도 있고 다른 변수들이 있어 예시보다는 쬐~금 복잡하지만 allocate와 deallocate 부분만 간단히 구현해보고 메모리를 제한하는 방법과 쓰레드를 처리하는 동작 방식에 대해 알아 두기로 한다. 코드를 보기 앞서 ByteBuffer.allocate와 ReentrantLock에 대해 먼저 알아보자. ByteBuffer.allocate  vs ByteBuffer.allocateDirect BufferPool은 allocate를 사용한다. 왜 allocateDirect를 사용하지 않는지는 여기 에 설명 되어 있는데, 간단히 요약하면 아래 정도의 내용이 된다. 생명주기가 짧거나 자주 사용되지 않는 객체에는 다이렉트 버퍼를 사용하지 않아야 한다. 왜냐하면, 다이렉트 버퍼는 OS 종속적인 네이티브 코드를 사용하기 때문에 힙기반 버퍼보다 생성과 메모리 반환 비용이 높고 가비지 컬렉터의 영역 밖이라 메모리 누수가 있을 수 있다. 용량이 큰 다이렉트 버퍼를 빈번하게 할당하면 OutofMemorryError가 생길 수 있다. 그리고, FileChannel 에서 non-direct Buffer와 direct Buffer 속도비교 ( FileChannel and non-direct buffer vs. FileChannel and direct buffer , 중국어! 코드와 그림만 보자) 버퍼가 256KB보다 작

 카프카 컨슈머 클라이언트 0.9.0 에 대한 글이 있어서 학습차 요약정리 해두기로 했음. 발번역이고 의역과 생략된 내용 있으니,,, ((((( ' ') 원문: http://www.confluent.io/blog/tutorial-getting-started-with-the-new-apache-kafka-0.9-consumer-client 원작자: Jason Gustafson  애초에 카프카는 스칼라로 만들어진 프로듀서와 컨슈머 클라이언트를 제공했다. 시간이 지나면서 이 API에 많은 제약이 있음을 깨닫게 되었다. 예를 들어, 컨슈머 그룹을 지원하고 Failover 처리하는 ‘high-level’ 컨슈머 API가 있지만 더 복잡한 시나리오를 지원하지 못했다. 그리고 풀 컨트롤을 제공하는 “simple” 컨슈머 클라이언트가 있지만 사용자가 Failover와 에러 처리를 직접해야 했다. 그래서 다양한 사례를 처리하기 위해 클라이언트를 다시 디자인하기 시작했다.  첫 단계로 0.8.1에 Producer API를 다시 작성하고, 두 번째 단계로 새( new ) 컨슈머 API 소개하는 0.9 배포가 최근에 완료되었다. 카프카에서 제공하는 새( new ) 그룹 코디네이션 프로토콜 기반으로 새 컨슈머를 개발하면 아래와 같은 이점을 가질 수 있다. 깔끔하게 통합된 API: 새 컨슈머는 예전의 “심플” 하고 “고수준" 컨슈머 클라이언트의 두가지 능력을 결함하고,  자신만의 소비 전략을 만들기 위해 그룹 코디네이션과  저수준의 접근성 두가지를 결합한다. 의존성 감소: 새 컨슈머는 순수 자바로 작성 되었다. 스칼라 런타임이나 주키퍼에 의존성이 없어 서 프로젝트에 포함 시킬 수 있는 더 가벼운 라이브러리를 만들 수 있다. 향상된 보안: 카프카 0.9에 구현된 보안확장 은 새 컨슈머에만 지원된다. 또한, 새 컨슈머는 컨슈머 프로세스 그룹의 Fault-Tolerant를 관리하기 위해 프로토콜 세트( set )를 제공 한다. 이전에 이