Zero's hobby blog.

파라미터 전달 순서 왼쪽 -> 오른쪽 파라미터 순서대로

Integer & Pointer ->  rdi, rsi, rdx, rcx, r8, r9

floating-point(float, double) -> xmm0, xmm1, xmm2, xmm3, xmm4, xmm5, xmm6, xmm7

파라미터는 오른쪽부터 왼쪽 순으로 스택에 push 되고 함수 호출 후 caller(호출자)에 의해 정리 되어야 한다. 

함수가 호출되어지면 return address는 rsp에 위치하고 첫번째 파라미터는 rsp+8로 참조된다 

스택포인터 rsp는 16바이트 단위로 정렬 되어야 하지만

서브루틴 호출의 리턴 어드레스는 8byte만 push 하기 때문에

16바이트 경계를 맞춰주기 위해 rsp에서 8바이트를 더하거나 빼야 한다.

서브루틴이 보존해야 하는 레지스터는 

rbp, rbx, r12, r13, r14, r15 이며,  나머지 모든 레지스터는 자유롭게 서브루틴에서 변경 할 수 있다.

64bit 오라클 클라이언트 ODBC 설치시 MFC빌드 또한 64bit로 해야한다. 

32bit ODBC등록과 64bit ODBC등록은 나뉘어져 있으며 

32bit ODBC등록은 syswow64폴더에서 따로 해야한다.

메이븐 버전 : 3.3.3

센토스 버전 : 7

먼저, 메이븐 3.3.3 버전을 사용하려면 JDK 1.7 이상의 버전이 설치되어 있어야 한다. 

CentOS 에서 jdk 설치하기. 

yum list | grep jdk 

설치가능한 jdk 패키지의 목록.

원하는 버전 설치.

yum -y install java-1.8.0-openjdk-devel.x86_64

메이븐 다운로드 페이지 : https://maven.apache.org/download.cgi#

Binary 아카이브 파일 아무거나 받으면 된다 (zip , tar.gz) 

압축을 풀고나면 bin폴더에 메이븐의 실행파일 mvn이 들어있다. 

먼저 mvn을 실행하기 위한 환경변수를 설정하자. 

JAVA_HOME, PATH 설정

(자바의 설치 위치는 which 명령과 ls -l 명령으로 링크를 계속 따라가 찾을 수 있다.)

홈 폴더의 .bashrc 파일에서 환경변수를 추가 해준 뒤 

source ~/.bashrc 로 현재 SHELL에도 적용시킨다.

sestatus 

명령으로 현재 SELinux 가 실행중인지 확인할 수 있다.

/etc/sysconfig/selinux 

파일에서 

 SELINUX 값을 disabled로 설정한 뒤 재부팅 하면 SELINUX를 사용하지 않는다.

어느 Makefile에서 정의되지 않은 변수 때문에 몇 시간을 헤매다가 GNU사이트에서 해답을 찾았다. 

https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

${CC}, ${RM}같은 변수는 재정의 하지 않는 이상, cc, rm 의 명령을 변수로서 바로 사용이 가능하다. 

서버측에서 원격접속 설정이 모두 완료되었는데도 툴에서 접속이 안된다면, 

구 버전의 인증 프로토콜을 사용하도록 Advanced 에서 설정하자. 

웹서버에 모바일 홈페이지를 또 다른 톰캣에 담아 서비스 하던 중,

ssh 연결만 끊으면 404 에러가 뜨는 문제가 생겼다. 원인을 찾아보니 간혈적으로 WAS가 올라간 볼륨의 마운트가 해제되는 문제였다.

모바일 홈페이지는 /home/hanbat 폴더에 위치했다.

df -h 출력

/dev/mapper/tts-root 231214136 175502676  43966388  80% /
none                   2047104       212   2046892   1% /dev
none                   2054268       140   2054128   1% /dev/shm
none                   2054268       136   2054132   1% /var/run
none                   2054268         0   2054268   0% /var/lock
none                   2054268         0   2054268   0% /lib/init/rw
/dev/sda1               233191    105543    115207  48% /boot
/home/hanbat/.Private
                     231214136 175502676  43966388  80% /home/hanbat

보다시피 메인 디스크 볼륨은 / 로 마운트 되어있다.

헌데 맨 마지막줄에도 루트와 똑같은 용량으로 /home/hanbat/.Private 가 /home/hanbat으로 마운트되어 있는 아이러니한 구조다.

이 서버는 단일 디스크로 /home/hanbat 에 마운트된 볼륨과 /는 완전히 동일한 디스크다.

타 업체가 구성한 서버였기에 자세한 내용을 몰라 이리저리 찾아보던중 디스크 암호화 관련 유틸을 찾아냈다.

ubuntu 의  ecryptfs-utils 위 구성은 이 유틸로 /home/hanbat/.Private 라는 폴더를 /home/hanbat 으로 재 마운트 한것이다.

즉, .Private 폴더가 /home/hanbat으로 보이도록 마운트를 재구성 했다고 볼 수 있다.

실제 디스크의 /home/hanbat/.Private 에 가보면 암호화된, 알아볼 수 없는 파일들만 잔뜩 들어있다. 복호화키에의해 이 파일들이 복호화 되면서

/home/hanbat 처럼 보이는 것이다. 그리고 /home/hanbat/.ecryptfs 폴더에 이와 관련된 설정 파일들이 있다. 

hanbat@tts:~/.ecryptfs$ ls
Private.mnt  Private.sig  auto-mount  auto-umount  wrapped-passphrase

5개의 설정 파일이 있는데 이중 auto-mount와 auto-umount는 내용이 빈 파일로 단지 암호화된 디스크의 자동 마운트 및 언마운트 설정용 config다

메뉴얼을 찾아보니 auto-mount 는 로그인할 때 자동으로 마운트하는 옵션이고 auto-umount는 로그아웃할 때 자동으로 언마운트 하는 옵션이다.

이 설정으로 인해서 ssh연결을 끊으면 마운트되어있던 볼륨이 언마운트 되면서 /home/hanbat 으로 둔갑하고 있던 /home/hanbat/.Private 가 사라지고

본래의 /home/hanbat 으로 변하게 된다.

모바일 WAS를 올려둔 것은 홈 폴더로 둔갑했던 /home/hanbat/.Private 이므로 웹 서버가 파일들을 찾을 수 없던 것이다. 

이 디스크 암호화 유틸의 마운트는 /etc/fstab 설정에 전혀 나타나 있지 않다.

인수인계에서 해당 내용을 전달 받지 못했다면, 나중에 꽤나 고생을 해야할지도 모른다. 

마운트가 해제되는 문제는 auto-umount 파일을 삭제함으로써 해결했다.

마켓 플레이스에서 Eclipse Color Theme (코딩 컬러 스키마 모음) &

Eclipse Moonrise UI Theme (이클립스 UI 테마) 설치

추가 플러그인으로 설치된 Color Theme 에서 코드 컬러 스키마 설정

튜닝 끝.

토비의 스프링 3.1 p.670의 내용을 진행한뒤 테스트를 돌려보면 EmbeddedDatabase 에서 에러가 발생해 테스트의 일부가 실패한다.

에러의 원인은 중복 스크립트 실행이다. (테이블이 이미 있는데 또 다시 생성 스크립트 실행)

원인을 파악하기 위해 학습테스트를 여럿 만들고 테스트 소스를 여기저기 수정해가며 파악해 봤다.

 @DirtiesContext 가 문제의 원인이었다.

이 애노테이션은 빈의 DI설정을 변경할경우 다음 테스트를 실행할 때 새로운 컨텍스트를 생성케 한다

문제는, 이 애노테이션으로 생성되는 컨텍스트는 완전히 새로운 컨텍스트가 아니라는 것이다.

컨텍스트가 빈을 다시 생성할 때 내장형 데이터베이스 역시 새로운 메모리에 생성해서 돌려주어야 하는데, 이 애노테이션으로 생성된 컨텍스트는

기존에 생성됐던 내장형 데이터베이스에 다시 작업을 진행한다.

이 과정에서 이미 테이블까지 완성시킨 내장 데이터베이스에 다시 한 번 테이블 스크립트를 실행하고 SQL익셉션을 내뱉는 것이다.

왜 이렇게 작동하는지는 아직 정확한 이유를 알 수 없다.

한가지 알 수 있는것은 @DirtiesContext 는 컨텍스트를 완전히 새로 생성하는 것이 아니라는 것이다.

DI의 정보가 수정된 빈만 새로생성해서 돌려주거나 하는 특수한 작업을 하는 것으로 추측된다.

Junit 테스트는 컨텍스트 생성에 실패하고 다음 테스트에 다시 한 번 완전히 새로운 컨텍스트를 생성해 진행하게 된다.

(이 부분은 온전히 새로운 컨텍스트이기에 내장형 데이터베이스도 새로 생성되며 스크립트의 중복실행 또한 없다.)

결과적으로 @DirtiesContext 이후에 새로생성된 불완전한 컨텍스트로인해

@DirtiesContext이 붙은 테스트 바로 다음에 실행되는 테스트는 컨텍스트를 생성하는 과정에서 스크립트 중복실행으로 테스트가 실패하는 것이다.

@DirtiesContext 이 빈을 재생성할 때 어떤 작업을 하길래 이러한 문제가 발생하는지 해결 방법은 없는지

언젠가 스프링의 소스코드를 분석하게되면 찾아봐야겠다.