http://krakenapps.org/changeset/1034/kraken-rpc
맨날 새벽에 코딩했더니 코너 케이스를 제대로 고려 못 한데다 어제 밤샘의 여파로 몽롱한 정신에 이놈의 버그 파악하고 잡기가 어려웠다.. 대체로 지난 번에 양쪽에서 blocking call 할 때 서로 응답 못 하고 waiting 하는 것 때문에 메시지 핸들링을 스레드풀을 이용해서 하도록 바꾸고, 접속 직후 자동으로 한 번의 피어링을 동기적으로 수행하도록 하고 나서 생긴 문제들인데..
1. rpc-control 세션은 항상 존재한다고 가정하고 있는데 병렬화되면서 피어링 요청 메시지가 rpc-control 세션 셋업이 완료되기 전 날라오는 바람에 rpc-control을 못 찾고 성공해야 할 피어링이 바로 실패하게 됨.
2. 바보같이 원격지로 예외 던질 때 ret-for 헤더를 메시지 ID와 똑같이 써놔서, RPC 세션 요청에 대한 응답을 무한 대기 하는 도중에 (이건 일단 무조건 5초 타임아웃으로 변경함) 예외가 발생했는데 ID가 잘못 써있어서 예외를 못 받고 영원히 그대로 잠겨버림. 정신줄 놓고 코딩한 대표적인 예 -_-
3. 커넥션에 사용자정의 RPC 서비스가 자동으로 바인딩 되는 기능이 있는데, kraken-base가 자동으로 바인딩 될 것을 가정하고 kraken-sentry가 접속 직후 kraken-base 서비스에 대한 세션을 맺으려고 했으나 역시 서비스 바인딩이 늦어지면서 서비스를 찾지 못하고 바로 실패함.
일단 강제로 무조건 서비스에서 RPC 예외를 던지게 한 상태에서 지금까지 발견된 이슈들은 해결했는데 다른게 또 숨어있을지는 또 진행해봐야 알겠지 뭐... 아이고 시간 아까워..
+ 그래도 이 삽질 하면서 thread.interrupt 명령어 인수 파싱 잘못하는 버그를 찾아서 수정함 -_-;; 그래도 저런 정신나간 스레드들 런타임에 콘솔에서 확인하고 제어할 수 있는게 어디야..
덧글