스톰(Apache Storm)은 LMAX Disrupter를 통해 publish/consume 구조를 갖고 있다.

스칼라는 Akka(Actor) 모델을 기반으로 병렬 처리 패러다임을 갖고 있다면,,

LMAX Disrupter는 큐(RingBuffer) 모델을 기반으로 병렬 처리 패러다임을 갖고 있다. 즉 concurrey와 lock 이슈를 최대한 쉽게 해결하려하는 플랫폼이다. 

마치 AWT의 EventDispatchQueue 또는 Single Thread 기반의 Queue 병렬 처리 패러다임과 비슷해 보인다.

또한 input/output 모델에 대한 복제, 전달, 백업 이런 형태들도 포함한다. 

큐잉과 index가 있으며 장애가 발생하면 한번에 배치처리도 할 수 있으리라..

개념을 잡기 위한 자료는 다음과 같다.

https://www.slideshare.net/trishagee/workshop-introduction-to-the-disruptor

이전 그림보다는 조금더 상세한 그림

https://www.slideshare.net/trishagee/a-users-guide-to-the-disruptor

이건 QCon 동영상이다.

https://www.infoq.com/presentations/LMAX

관련 홈피이다.

http://lmax-exchange.github.io/disruptor/

마틴파울러가 정리한 LMAX 아키텍처이다.

https://martinfowler.com/articles/lmax.html

소스 리파지토리이다.

https://github.com/LMAX-Exchange/disruptor

자바스크립트/CSS를 처음 하는 입장에서는

화면 구성을 어떻게 해야 할지 잘 보이지 않는다.

UI 컴포넌트를 수평으로 두어야 할지, 수직으로 둬야 두려면 flex를 사용한다. 

그리고 가운데 정렬할 지에 대한 내용은 간단하게 아래 키워드를 사용한다.

간단한 개념에 대한 설명 자료는 다음과 같다. 

https://joshuajangblog.wordpress.com/2016/09/19/learn-css-flexbox-in-3mins/

아주 자세한 내용은 다음을 참조한다.

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

https://msdn.microsoft.com/ko-kr/library/bg124109(v=vs.85).aspx

foreach 문에 함수를 사용해 주어진 매개변수의 속성을 접근해서 배열에 저장(push) 할 때 

아래처럼 속성을 접근할 때 점(.)을 사용하면 에러가 발생한다.

이럴 때는 [,]을 사용해 속성을 접근하는 방법이 있고 에러는 발생하지 않는다.

즉 다음 2개는 동일하다.

item.timestamp = '111';

item['timestamp'] = '111';

자바 1.8에서 gc 로그 설정을 잘 해야 한다. 그냥 파일에 출력만 하기로 결정한다면 큰 이슈가 발생할 수 있다.

즉 gc로그를 jvm에서 저장하고 있기 때문에 jvm에 크게 영향을 줄 수 있다.

kafka 서버의 gc로그를 간단히 설정한 결과는 다음과 같다. 5G의 메모리가 저장되어 있다.

$ cp /dev/null kafkaServer-gc.log

cp: overwrite `kafkaServer-gc.log'? y

$ ls -al kafkaServer-gc.log

-rw-r—r— 1 kafka kafka 0  1월 12 10:42 kafkaServer-gc.log

$ ls -al kafkaServer-gc.log

-rw-r—r— 1 kafka kafka 5727854571  1월 12 10:43 kafkaServer-gc.log

재시작을 해보면 gc 로그 크기만큼 jvm메모리가 변경되어 있다. 

따라서 jvm에서 gc로그를 특정 크기로 여러 개의 파일로 설정해야 한다.

jvm의 gc 로그를 사용할 때 아래와 같이 사용하는 것이 좋다. 디스크 용량을 넘어서지 않도록 용량/크기를 제어해야 한다.

gc 로그 파일을 작은 크기로, 여러 개로 나누거나

JVM_FLAGS="-verbosegc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:logs/gc.log -XX:+UseGCLogFileRotation -XX:GCLogFileSize=1m -XX:NumberOfGCLogFiles=100 "

gc 로그파일을 크고 작은 크기로 나눠도 좋을 것 같다.

JVM_FLAGS="-verbosegc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:logs/gc.log -XX:+UseGCLogFileRotation -XX:GCLogFileSize=100m -XX:NumberOfGCLogFiles=5"

전역 변수는 아래와 같이 _를 사용해서 정의할 수 있다.

var i: Int = _

var s: String = _

로컬 변수는 아래와 같이 

var response: LogResponse = _

string(object) 타입을 Boolean 값으로 변환하고 싶을 때. 다음과 같이 사용한다.

var a = Boolean(aaaa);

카프카 서버 성능에 크게 영향을 미치는 요인이 acks, retries, batch.size 이다..

https://www.slideshare.net/JiangjieQin/producer-performance-tuning-for-apache-kafka-63147600

https://www.youtube.com/watch?v=oQe7PpDDdzA

https://ko.hortonworks.com/blog/microbenchmarking-storm-1-0-performance/

self time - 메소드에서 소요된 전체 시간(락/블러킹 포함)

self time(cpu) - 메소드에서 소요된 전체 시간(락/블러킹 제외) 

두 값을 비교하면 멀티 쓰레드 환경 관점으로 특별히 비교할 수 있다.

Play2-React를 개발하던 중에 아래와 같은 에러가 크롬에서 발생했다. 

https://www.playframework.com/documentation/2.6.x/CorsFilter를 참고로 설정을 수정했다.

play.filters.enabled += "play.filters.cors.CORSFilter"

play.filters.cors {

  pathPrefixes = ["/", ...]

  allowedOrigins = ["http://localhost", ...]

  allowedHttpMethods = ["GET", "POST"]

  allowedHttpHeaders = ["Accept"]

  preflightMaxAge = 3 days

}

처음에는 404, 정책을 잘 지정하지 못하면 403이 나타난다.

allowedOrigins = ["http://localhost:9000", ...]

다음과 같이 모두 개방하면 테스트는 편해진다. 상용에서는 보안을 위해서 잘 수정하는 것이 좋다. 

(테스트용)

play.filters.hosts {

  allowed = ["."]

}

(상용)

play.filters.hosts {

    allowed = ["localhost", ".kakao.com", "localhost:9000", "local.google.com:9000", "local.google.com:4200"]

}

클라이언트(js)에서도 다음과 같이 수정한다. 

이제 요청하면 정상적으로 동작하는 지 확인할 수 있다.