두 손끝의 창조자

git reflog --date=local [branch]

대용량 파일을 읽어 라인별 처리를 하는 것을 시도하였다. DirectByteBuffer를 사용한 이유는 대용량 데이터를 시스템에서 읽어서 jvm에 올리는 비용을 줄이고자 함이었다. 내가 필요한 작업은 파일을 일어서 행별로 읽어들이는 거였는데 DirectByteBuffer는 행단위 Reader를 제공하지 않는다. 그래서 별도로 구현을 했는데 구현 과정에 byte배열에 복사하고 하는 과정이 제법 있어서그런지 이렇다할 성능개선은 보이지 았았고 오히려 느려졌다. DirectByteBuffer는 데이터를 읽어 별도로 다른 buffer에 넣지 않고 즉시처리, 예를 들어서 다른 socket으로 보낸다던지 하는 경우 성능개선에 도움이 될 것같다. import sun.nio.ch.DirectBuffer; import j..

github에서 PR을 올렸는데 실패하거나 수정 요청이들어오면 어떻게 하나? 일단 PR에 올라가는 커밋은 단일 커밋으로 해야 프로젝트 이력관리에 유리하게 때문에 그렇게 해야한다. 수정을 하면 커밋이 하나 더 발생할 텐데 그럼 어떻게 하냐? 로컬에서 변경사항을 만들어서 커밋 한 뒤에 한 커밋으로 다시 만든다. 한 커밋으로 만드는 것은 rebase --interactive로 해도 되고 내 같은 경우는 그냥 git commit --amend 로 전 커밋과 바로 합쳐서 한 커밋으로 만들었다. push -f 로 강제로 올리면 github에 올라간 pr도 같이 자동으로 새로운 커밋id로 변경되면서 다시 프로세스가 진행된다. 긋긋 가장 좋은건 올리기전에 체크체크체크

파일을 찾을 수 없을 때 주로 이 예외가 발생하지만, 파일이 너무 많이 열려있어서 OS에서 파일 여러는 것을 막아버릴수도 있다. 이때도 FileNotFoundException 이 발생한다. 메시지는 "Too many open files". 현재 OS에 설정되어 있는 최대 파일 오픈가능 개수를 확인한다. ulimit –a 명령어로 open files 설정값을 확인한 뒤 현재 특정 프로세스에 의해 열린 파일들도 확인한다. lsof -i :[port] 로 특정 포트를 사용하고 있는 프로세스를 확인한다. lsof -p [PID] | wc –l 로 현재 오픈되어 있는 파일들의 개수를 확인하고 적절한 값으로 변경한다. ulimit -n [변경개수] 명령어로 변경한다.

NioEndpoint->AbstractProtocol#process->Http11Processor#service->CoyoteAdapter#service 프로토콜이(HTTP/1.1 이면 Http11NioProtocol) 소켓에서 요청 정보를 받아서 처리할 프로세서를 가져온다. 프로세서는 AbstractProcessorLight를 구현한 구현체가 반환될텐데 HTTP/1.1이면 Http11Processor를 선택 할 것이다. 프로토콜은 프로세서의 service 메소드를 호출하면서 요청처리를 넘긴다. 프로세서에서는 처음으로 Request, Response 객체가 등장하고 CoyoteAdapter의 Service를 호출하면서 컨테이너에 Resquest와 Response객체를 넘긴다.