내가 와우하는 맛

파티가 해딩하는 경우에 문제점을 찾아 보강하고 재도전해는 것. 그렇게 반복하다가 결국에 성공하는 것. 그맛에 하는 듯.

나머지 자잘한 템랩 높이는거, 골드 모으기, 업적, 탱(야탱), 딜(파흑), 힐(수사) 등 투기장(pvp)빼고 다 해보고 있지만 역시나 트라이 하다가 성공할때가 제일 재밌는것 같다.

우리네 인생도 그러길 바란다.

수많은 실패를 두려워 말고 실패했을 때 문제를 보강해 재도전할 수 있기를 바란다.

그러다 언젠간 보라둥이로 변신한 가로쉬를 킬하는 순간처럼 킬할 수 있기를 바란다.

i2068562303

블로그 리뉴얼 중

1. 블로그 다시 살림.

2. 책 관련 링크 복구.

3. 모든 워드 프레스 플러그인 비활성화.

4. Guest 페이지 삭제.

5. 페북 코멘트 플러그인 활성화

6. Akismet 플러그인 활성화 (스팸 댓글 방지)

7. 저서와 번역서 이미지 수정

8. ssh sftp updater 플러그인 활성화

9. gist 플러그인 삭제

10. gist shorcode 플러그인 추가 및 활성화

톰캣 클래스로더 계층 구조

서블릿 안에다가

ClassLoader contextCL = Thread.currentThread().getContextClassLoader();
System.out.println(“=============== Thread ClassLoader ================”);
System.out.println(“ContextClassLoader: ” + contextCL);
System.out.println(“Parent Of ContextClassLaoder: ” + contextCL.getParent());
System.out.println(“GrandParent Of ContextClassLaoder: ” + contextCL.getParent().getParent());

System.out.println(“=============== System ClassLoader ================”);
ClassLoader parentCL = ClassLoader.getSystemClassLoader();
System.out.println(“SystemClassLoader: ” + parentCL);
System.out.println(“Parent Of SystemClassLoader: ” + parentCL.getParent());
System.out.println(“GrandParent Of SystemClassLoader: ” + parentCL.getParent().getParent());

이렇게 찍었다. 역시 최고의 디버깅은 sout이지.

결과는..

=============== Thread ClassLoader ================
ContextClassLoader: WebappClassLoader
context:
delegate: false
repositories:
/WEB-INF/classes/
———-> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@28d47c65

Parent Of ContextClassLaoder: org.apache.catalina.loader.StandardClassLoader@28d47c65
GrandParent Of ContextClassLaoder: sun.misc.Launcher$AppClassLoader@247973e4
=============== System ClassLoader ================
SystemClassLoader: sun.misc.Launcher$AppClassLoader@247973e4
Parent Of SystemClassLoader: sun.misc.Launcher$ExtClassLoader@21a79071
GrandParent Of SystemClassLoader: null

그러하다. 자세한 설명은 생략.

스프링 MVC Test와 Spock 같이 쓰기

시간이 여유치 않아서 길게 포스팅하기는 힘들고..

Spock은 이번 스프링원에서 알게된 테스트 프레임워크인데, 이 프레임워크 관련 세션이 세개나 있었다.

  • Next Level Spock
  • Testing Controllers with Spring MVC Test and Spock
  • Spock Friendly Testing

https://code.google.com/p/spock/wiki/SpockBasics

스팍은 스타트랙에 나오는 캐릭터인데… 멋진 캐릭터이다. 마치 우리팀에 있는 응준대리님같은 캐릭터인데… 자세한건 생략…

스프링 MVC Test는 그동안 많이 떠들었으니까 역시 생략..

둘이 합쳐서 간단한 테스트를 만들어 보면 이렇게 만들 수 있다.

조금 더 복잡하지만 실용적인 테스트는 보통 이런식이 될거다.

[ElasticSearch] 개념 정리

몇가지 용어만 알면 될것 같은데.. 하두 흔히 사용하는 용어를 사용해서 햇갈린다.

http://www.elasticsearch.org/guide/reference/glossary/#id

일단, 데이터베이스에 해당하는 용어가 index. 인덱스는 최소 한개 또는 그 이상의 primary shard에 대응하는 논리적인 이름이다.

테이블에 해당하는게 type.

type에 들어가는 한 데이터(row)는 document. document는 index에 저장되고 type과 id가 있다. 한 document에는 여러 field나 키-값 쌍이 들어있다.

type을 정의하는 스키마에 해당하는게 mapping.

테이블의 컬럼에 해당하는게 filed.

원본 JSON 담고 있는 필드가 source filed로 _source라는 필드가 있다.

document 식별자가 id.

============

text를 analysis해서 term으로 인덱스 시킨다.

text는 글 덩어리?

analysis는 전체 글을 term으로 바꾸는 과정이고 엘라스틱서치는 term을 index시킨다. 풀 텍스트 검색도 결국은 검색어를 term으로 바꿔서 term 검색에 대응되는 녀석 찾아주는 식으로 처리된다.

============

cluster는 동일한 클러스터 이름을 가진 여러 node로 구성된다. 클러스터에는 클러스터가 자동으로 지정한 마스터 노드가 한개 있으며, 마스터 노드가 죽으면 다른걸로 바뀔 수 있다.

node는 클러스터에 속한 실행중인 엘라스틱서치 인스턴스다. 보통 서버당 하나만 사용하지만 테스트용으로 여러개 써보는거야 뭐.. 노드를 실행할 때 클러스터 이름으로 기존 클러스터를 찾아서 그안에 들어갈 수 있는데 이때 unicast나 multicast를 사용할 수 있다.

document를 저장하는 곳이 primary shard인데, primary shard에 먼저 document를 인덱스 시킨다음에 해당 primary shard의 모든 replica shard로 복사한다. 기본값으로 한 index마다 5개의 primary shard를 가지는데, 설정으로 변경 가능. 인덱스를 일단 만들고나면 primary shard 개수를 변경할 수 없다.

routing은 index에 저장할 document를 실제 어떤 primary shard에 저장할지 정하는 과정인데 document의 id값을 해싱한 routing 값을 사용하거나, document가 parent document를 가지고 있다면 해당 parent의 id값을 사용해서 부모랑 자식이 같은 샤드에 들어가게 한다. routing 값 오버라이딩 하거나 mapping할 때 설정하는 방법은 나중에.

replica shard는 두가지 목적으로 사용하는데, 하나는 페일오버로 primary shard가 죽을 때 replica shard를 primary shard로 승격시켜서 사용하기 위함이고 두번째는 성능으로 get이나 search를 primary shard와 replica shard로 처리해서 성능 향상. 기본값으로 primary shard당 한개의 replica shard를 가지고 기존 index에 동적으로 replica shard를 추가할 수 있다. primary shard와 같은 노드에서 시작하지 않는게 좋다.

shard 한개는 루씬 인스턴스 한개다. 엘라스틱서치가 관리하는 저수준의 “worker”이고, 여러 primary 샤드와 replaca 샤드 묶음을 논리적인 이름으로 나타내는게 index다. 샤드 개수 설정할 때 빼고 코딩할 때는 샤드를 직접 지칭할 일은 없고 index를 사용할 것이다. 엘라스틱서치가 클러스터의 여러 노드로 샤드를 분산시킨다. 샤드는 노드가 죽거나 새 노드가 추가될 때 동적으로 다른 노드로 옮겨질 수 있다.

=============

아 놔 이제야 좀 정리가 되네..

그러니까.. 노드는 엘라스틱서치 인스턴스고, 그 안에 인덱스 만들면 샤드라는 루씬 인스턴스가 생기는데 기본값으로 인덱스마다 primary 샤드 5개랑 각 primary 샤드당 replica 샤드가 1개씩 생기니까 기본으로 인덱스 하나 마다 10개의 루씬 인스턴스가 뜨는거네..

흠.. primary 샤드 개수는 어느 정도가 적당한거지?