반응형

부끄러운 사실이지만, 최근 들어서야 코딩할 때 파이썬(python)을 쓰기 시작했다.

말이 최근이지 불과 이틀 전이다. ㅡㅡ;;


애초에 네트워크 시뮬레이션 특성상 핵심 구현은 C/C++을 쓸 수밖에 없고, 똑같은 것을 실제 장비에서 실험을 해보려면 리눅스 디바이스 드라이버를 고쳐야 해서 결국 C를 써야 한다. 전에 연구실에서 IoT 테스트베드 구현에 깊게 참여하던 당시에는 IoT 미들웨어가 순수 Java로만 되어 있었고, 과제 연차평가를 보여줄 시연용 모바일 기기도 안드로이드여서 Java 기반이니 지금껏 Java와 C/C++만 줄기차게 써온 셈이다.


물론 스크립트 언어를 안 쓴 것은 아닌데, 그게 리눅스 쉘(shell) 스크립트와 awk였다. QualNet이나 ns-3가 만들어 내는 수많은 반복 시뮬레이션을 batch로 실행하고, 실행 후에 만들어지는 여러 개의 데이터 텍스트 파일들을 정리해서 엑셀이나 Gnuplot에 붙이기 좋게 만들 필요가 있었다. 

문제는 shell (bash)이든 awk든 스크립트 언어라서 바로바로 돌려볼 수 있기는 한데, 왠지 코드가 쉽게 써지지 않는 것은 단지 나의 기분탓이었을까? (...)


사실 bash나 awk 모두 잘(?) 쓰면 아주 강력한 스크립트 언어인 것은 분명하지만, 이상하게 빨리 익숙해지는 느낌은 잘 들지 않았다. 내가 집중적으로 실험할 때에만 폭풍처럼 몰아쳐서 스크립트를 만들다가 또 한참 안쓰고 잊어버려서 그런 것일지도? 아무튼 awk로 내가 머릿속에서 상상하는 것처럼 텍스트를 예쁜 과일 자르듯 쉽게 파싱하려면 상당한 시간의 구글링과 trial-and-error를 거쳐야만 했다.


최근에도 bash와 awk의 조합으로 ns-3 시뮬레이션을 대량으로 돌리고, 그 결과로 생성되는 텍스트 파일 중에서 몇몇 지정된 노드 번호에 대해서만 로그 데이터를 읽어들여서 파싱하는 작업을 했는데, 최근에 요구사항이 추가돼서 결과 데이터를 한번 더 가공해야 하는 상황이 되었다.

이미 만들어 놓은 awk 코드를 또 고치려니 선뜻 손이 가지 않아서, 차라리 파이썬으로 해 봐야겠다는 생각이 들어서 그냥 파이썬의 파일 입출력 예제 코드와 string 포맷팅 등의 기초적인 정보를 구글링해서 만들어 보았다.


그랬더니,


...15분 만에 결과 데이터가 내가 원하는 형태로 터미널 화면에 뙇.


Aㅏ...


기존의 awk와 shell 스크립트를 뜯어고치면 절대 완성하지 못할 시간인데...

그리고 다른 데이터에 대한 유사한 후처리 작업을 ns-3 시뮬레이션 상에서 C++ 함수로 구현해 둔 것도 있는데, 그 당시에 구현하던 때에도 30분 넘게 걸렸었는데 파이썬은 문법을 구글링하고 vi에서 생으로 코드를 짰는데도 15분이라니.

게다가 그동안 자바로 코딩했던 경험상, 똑같은 기능을 자바로 구현하면 100줄은 쉽게 넘어갈 코드가 파이썬에서 주석과 디버그용 print문 합쳐서 45라인...


...난 지금까지 뭘 한거지? ㅋㅋㅋㅋㅋ


예전에 오버레이 네트워크 상에서 돌리는 라우팅 프로토콜을 만들어야 된다고 징징거릴 때, 주변에서 파이썬으로 먼저 만들어 보는 건 어떠냐는 제안에도 파이썬을 써본 적이 전혀 없어서 익숙한 Java로 하겠다고 그랬는데...

테스트용 웹서버 구축할 때에도 Spring Boot 상에서 자바로 노동(?)을 하고 있을 때에도 옆에서 아는 형이 Django로 파이썬으로 만들면 더 빠르다고 했을 때에도 선뜻 바꿀 생각을 못했는데... @_@ (정신 가출)


다양한 프로그래밍 언어로 문자열 처리 어플리케이션 개발 시 소요되는 시간 비교(Prechelt and Garret) (출처: HACKERNOON [1])


위의 그래프가 충분히 이해가 가는 순간이다.


게다가 내가 목표로 하는 개발환경은 실행속도 따위(...) 그다지 의미가 없고, 코드만 빨리 완성되면 가상 머신 여러 개 만들어서 밤에 자는 동안 batch로 잔뜩 돌려놓기만 하면 되니까... 진작에 파이썬을 여기저기 적용해서 쓸 걸 ㅠㅠ


게다가 파이썬을 단 한번도 써본 적 없다고 괜히 겁먹은 거잖아?!

기존에 다른 프로그래밍 언어들을 장시간 다뤄본 사람 입장에서 파이썬은 배울 필요 없이 그냥 일단 쓰고 보면 되는 거였다. ㅡㅡ;;


물론 텍스트를 잘 파싱/편집/재구성하는 가장 강력한 도구로써 awk를 쓰는 것이 여전히 더 유리한 상황은 있을 것이다. 하지만 비교적 단순한 스트링 파싱은 그냥 파이썬에서 직관적인 코드를 써서 훨씬 더 빨리 만들어낼 수 있음을 이번에 경험으로 알게 되었다.

앞으로는 C++ 시뮬레이션 코드를 bash로 반복 실행을 하고, awk로 여기저기 흩어진 데이터를 한데 모으는 것까지만 하고, 그 뒤의 스트링 파싱이나 평균 계산 등은 다 파이썬으로 하면 될 것 같다.


생산성이 좋다고 주변에서 일관되게 얘기하면 그러한 줄 알고 신속하게 적용할 수 있는 사고방식의 중요성을 느낀다. ㅠㅠ

외곬수가 되지 말자...



<참고자료>

[1] Nick Humrich, "Yes, Python is Slow, and I Don’t Care," HACKERNOON,

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1



반응형
블로그 이미지

Bryan_

,
반응형


C/C++, Java로 코딩을 하다가 가끔 접하는 상황이 있는데, 같은 목적을 if-return의 조합과 if-else의 조합 모두로 코딩할 수 있을 때 어느 것을 선택해야 하는지에 대한 것이다.


int runSomeFunction(int a, int b){

if(condition_A){

return A;

} else {

do_something_1();

do_something_2();

}

}


--------------------------------------------------------


int runSomeFunction(int a, int b){

if(condition_A){

return A;

}


do_something_1();

do_something_2();

}


조건이 1개만 있을 때는 둘 사이에 별로 차이가 나지 않는 것 같다. 하지만 첫번째 조건 이후에 또다른 조건을 검사해야 하는 2개 이상의 nested condition이 생기면 조금 다르게 보이기 시작한다.



int runSomeFunction(int a, int b){

if(condition_A){

return A;

} else {

if(condition_B){

   return B;

} else {

   do_something_1();

   do_something_2();

}

}

}


--------------------------------------------------------


int runSomeFunction(int a, int b){

if(condition_A){

return A;

}


if(condition_B){

return B;

}


do_something_1();

do_something_2();

}


아무래도 indent가 nested condition의 수만큼 더 깊어지는(?) 문제가 생긴다. 사실 둘 사이에 성능상의 차이는 거의 없다고 보이고, 결국 코딩 스타일이나 가독성의 문제로 귀결되는 것 같다.


개인적으로는 if-return으로 처리하는 것을 선호하지만, 꼭 모든 경우에 다 if-return이 가독성이 좋다고 보기도 애매할 때가 있다. 가령, nested condition 정도가 심하지는 않으면서 각 조건마다 실행해야 하는 코드의 양이 비슷하면,



int runSomeFunction(int a, int b){

if(condition_A){

do_something_1();

do_something_2();

do_something_3();

do_something_4();

} else {

do_something_5();

do_something_6();

do_something_7();

do_something_8();

}

}


--------------------------------------------------------


int runSomeFunction(int a, int b){

if(condition_A){

do_something_1();

do_something_2();

do_something_3();

do_something_4();

return;

}


do_something_5();

do_something_6();

do_something_7();

do_something_8();

}


이런 경우에는 if-else가 서로 다른 조건에 대한 코드들의 차이를 알아보기에 더 좋은 것처럼 보인다.


if-return이 가장 효과적일 때를 생각해 본다면, 초반에 input parameter라던지 변수의 null 여부 같은 것을 확인해서 함수/메쏘드 나머지 부분의 실행 여부를 판단해야 할 때가 아닐까?


int runSomeFunction(int a, int b){

if(var_A == NULL) return;

if(var_B < 0) return;


do_something_1();

do_something_2();

do_something_3();

do_something_4();

}



결론적으로, if-else와 if-return 사이에 성능의 차이는 별로 없기 때문에 본인의 코딩 스타일과 가독성을 생각해 가면서 그때그때 상황에 맞게 정하는 수밖에 없겠다. Indentation을 많이 하는 것을 선호하지 않는다면 if-return 조합으로 코딩하는 비중이 좀더 늘어나는 정도로 생각하면 될 것 같고, 그게 꼭 정답이라기보다는 개인마다 가독성에 대한 기준도 다르니까, 맞춰서 쓰면 될 것이다.



<참고자료>

[1] http://stackoverflow.com/questions/9267643/if-return-vs-if-else-efficiency


반응형
블로그 이미지

Bryan_

,
반응형


JSP에서 자바 코드를 써서 image orientation을 먼저 알아내고,

orientation 숫자를 기준으로 회전해야 할 각도를 구해서 CSS가 회전을 수행하는 방식이다.



1. 필요한 라이브러리 다운로드 및 적용


이미지의 EXIF 정보에서 orientation을 알아내야 하기 때문에 Metadata-extractor를 쓴다.


[직접 다운로드 또는 사용법 설명]

https://github.com/drewnoakes/metadata-extractor


[Maven]

<dependency>
  <groupId>com.drewnoakes</groupId>
  <artifactId>metadata-extractor</artifactId>
  <version>2.9.1</version>
</dependency>

[Gradle]

 - dependencies에 추가

compile group: 'com.drewnoakes', name: 'metadata-extractor', version: '2.9.1'



2. 소스코드 작성


2-1. Metadata-extractor 기반의 자바 코드:


Java의 File 오브젝트를 사용해서 이미지 파일의 메타데이터 알아내는 Java 클래스를 정의한다.


import java.io.File;

import java.io.IOException;


import com.drew.imaging.ImageMetadataReader;

import com.drew.imaging.ImageProcessingException;

import com.drew.metadata.Directory;

import com.drew.metadata.Metadata;

import com.drew.metadata.MetadataException;

import com.drew.metadata.exif.ExifIFD0Directory;


public class ImageUtil {

/**

* Gets the orientation of an image (usually photo).

* Outputs:

* 6: rotate 90,

* 1: original (no change)

* 3: rotate 180,

* 8: rotate 270,

* others: original (no change)

* @param in a File object to check

* @return orientation value

* @throws IOException

*/

public static int getOrientation(File in) throws IOException {

int orientation = 1;

Metadata metadata;

Directory directory;

try {

metadata = ImageMetadataReader.readMetadata(in);

directory = metadata.getFirstDirectoryOfType(ExifIFD0Directory.class);

if(directory != null){

orientation = directory.getInt(ExifIFD0Directory.TAG_ORIENTATION);

}

} catch (ImageProcessingException e) {

System.err.println("[ImgUtil] could not process image");

e.printStackTrace();

} catch (MetadataException e) {

System.err.println("[ImgUtil] could not get orientation from image");

e.printStackTrace();

}

return orientation;

}

public static int getDegreeForOrientation(int orientation){

int degree = 0;

switch(orientation){

case 6:

degree = 90; break;

case 1:

degree = 0; break;

case 3:

degree = 180; break;

case 8:

degree = 270; break;

default:

degree = 0; break;

}

return degree;

}

}



2-2. CSS 정의


실제로 이미지 회전을 수행하는 CSS 코드를 작성한다. 

html 파일에서 <head> 태그 안에 넣거나, 별도로 쓰는 css파일에 추가한다.


<style type="text/css">

.rotate90 {

   -webkit-transform: rotate(90deg);

   -moz-transform: rotate(90deg);

   -o-transform: rotate(90deg);

   -ms-transform: rotate(90deg);

   transform: rotate(90deg);

}

.rotate180 {

   -webkit-transform: rotate(180deg);

   -moz-transform: rotate(180deg);

   -o-transform: rotate(180deg);

   -ms-transform: rotate(180deg);

   transform: rotate(180deg);

}

.rotate270 {

   -webkit-transform: rotate(270deg);

   -moz-transform: rotate(270deg);

   -o-transform: rotate(270deg);

   -ms-transform: rotate(270deg);

   transform: rotate(270deg);

</style>



2-3. JSP 소스코드


먼저 2-1에서 만든 자바 클래스를 JSP에 import한다.

<%@ page import="ImageUtil이_포함된_패키지_이름.*" %>



<%

String filePath = "이미지_파일의_경로";

File f = new File(filePath);

int orientation = ImageUtil.getOrientation(f);

int degree = ImageUtil.getDegreeForOrientation(orientation);


if(degree != 0){

%>

<img src="이미지_파일의_경로" class="rotate<%=degree%>">

<%

} else {

%>

<img src="이미지_파일의_경로">

<%

}

%>




반응형
블로그 이미지

Bryan_

,
반응형

Host OS: Ubuntu 16.04 (amd64)

Host Spec (VM): Quad core 2.6GHz (Intel Zeon, Haswell), 4GB RAM

LXC template: ubuntu



지난 여름에는 라즈베리파이 4개를 가지고 무선 메쉬 네트워크를 만들고, 각각의 라즈베리파이가 AP 역할을 함으로써 서로 다른 AP에 물린 클라이언트들 사이에 통신이 되도록 하였고, 이를 중개하는 multi-constrained 라우팅 프로토콜을 Java로 개발해서 테스트를 했었다.


사실 성능을 생각하면 C로 개발해야 하지만 무지막지하게 늘어나는 개발 시간 때문에 그나마 익숙하게 다룰 수 있는 Java로 개발을 했었고, 이제 와서 보니 이게 ns-3에서 시뮬레이션을 돌릴 때 결국 C나 파이썬으로 포팅해야 되는 어려움으로 돌아오고 말았다. ㄷㄷ


하지만 ns-3는 real-world program을 돌릴 수 있는 몇 가지 방법을 제시하고 있었고, 그 중에서 Linux Container (LXC)를 이용한 방법이 있어서 튜토리얼을 따라하며 환경을 구축해 보았다.


실제로 예제를 그대로 따라해서 2개의 노드가 IEEE 802.11g로 서로 애드혹 네트워크로 연결되고 각각의 노드에서 ping, ssh 등을 테스트하는 데에는 아무 문제가 없었다.

여기서 더 나가서 내가 개발한 Java 기반의 라우팅 프로토콜을 실행시키는 과정이 생각보다 오래 걸렸지만, 이것도 각 컨테이너를 인터넷에 먼저 연결시키고 apt-get으로 필요한 패키지를 다 설치하고 나니 어쨌든 내가 라즈베리파이에서 돌리던 모양 그대로 실행시킬 수 있었다.


여기까지는 일단 그대로 실행이 되는지부터 봐야 해서 노드 3개까지만 만들어서 해 본 거였고, 이제 본격적으로 시뮬레이션을 돌리기 위해서 노드 생성과 Java 프로그램 실행을 자동화하는 스크립팅 작업을 했는데 이것 또한 시간이 은근히 많이 걸렸다. ㅜㅜ


우여곡절 끝에 이제 내가 마음대로 원하는 만큼의 노드(컨테이너)를 자동으로 생성/실행할 수 있게 되었고, 네트워크 토폴로지는 ns-3에서 역시나 마음대로 설정해 주면 되었다.


드디어 대망의 첫 실험...

자신있게 10개의 노드를 명령어 한 줄로 간지나게(?) 자동으로 뙇 생성하고, 토폴로지는 4-4-2 그리드 형태로 만든 다음, 실험 시작을 누르고 나서 시범적으로 9번 노드에서 이웃 노드인 10번 노드한테 ping을 날려 봤더니...


root@node9:/# ping 10.0.0.10

PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.

64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=3665 ms

64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=4356 ms

64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=5375 ms

64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=7245 ms

64 bytes from 10.0.0.10: icmp_seq=5 ttl=64 time=8166 ms

64 bytes from 10.0.0.10: icmp_seq=6 ttl=64 time=9149 ms

64 bytes from 10.0.0.10: icmp_seq=7 ttl=64 time=10225 ms

64 bytes from 10.0.0.10: icmp_seq=8 ttl=64 time=11106 ms

64 bytes from 10.0.0.10: icmp_seq=9 ttl=64 time=12252 ms

64 bytes from 10.0.0.10: icmp_seq=10 ttl=64 time=13146 ms

64 bytes from 10.0.0.10: icmp_seq=11 ttl=64 time=14062 ms

64 bytes from 10.0.0.10: icmp_seq=12 ttl=64 time=15261 ms

64 bytes from 10.0.0.10: icmp_seq=13 ttl=64 time=16784 ms

64 bytes from 10.0.0.10: icmp_seq=14 ttl=64 time=18056 ms

64 bytes from 10.0.0.10: icmp_seq=15 ttl=64 time=19286 ms

64 bytes from 10.0.0.10: icmp_seq=16 ttl=64 time=20347 ms

64 bytes from 10.0.0.10: icmp_seq=17 ttl=64 time=21576 ms

64 bytes from 10.0.0.10: icmp_seq=18 ttl=64 time=22208 ms

64 bytes from 10.0.0.10: icmp_seq=19 ttl=64 time=22970 ms

64 bytes from 10.0.0.10: icmp_seq=20 ttl=64 time=23673 ms

64 bytes from 10.0.0.10: icmp_seq=21 ttl=64 time=24549 ms

64 bytes from 10.0.0.10: icmp_seq=22 ttl=64 time=24565 ms

64 bytes from 10.0.0.10: icmp_seq=23 ttl=64 time=24311 ms

64 bytes from 10.0.0.10: icmp_seq=24 ttl=64 time=24205 ms

64 bytes from 10.0.0.10: icmp_seq=25 ttl=64 time=23996 ms

64 bytes from 10.0.0.10: icmp_seq=26 ttl=64 time=23627 ms

64 bytes from 10.0.0.10: icmp_seq=27 ttl=64 time=23452 ms

64 bytes from 10.0.0.10: icmp_seq=28 ttl=64 time=23325 ms

64 bytes from 10.0.0.10: icmp_seq=29 ttl=64 time=23048 ms

64 bytes from 10.0.0.10: icmp_seq=30 ttl=64 time=22669 ms

64 bytes from 10.0.0.10: icmp_seq=31 ttl=64 time=22337 ms

64 bytes from 10.0.0.10: icmp_seq=32 ttl=64 time=21869 ms

64 bytes from 10.0.0.10: icmp_seq=33 ttl=64 time=21127 ms

64 bytes from 10.0.0.10: icmp_seq=34 ttl=64 time=20186 ms

64 bytes from 10.0.0.10: icmp_seq=35 ttl=64 time=19246 ms

64 bytes from 10.0.0.10: icmp_seq=36 ttl=64 time=18327 ms

64 bytes from 10.0.0.10: icmp_seq=37 ttl=64 time=17383 ms

64 bytes from 10.0.0.10: icmp_seq=38 ttl=64 time=16449 ms

64 bytes from 10.0.0.10: icmp_seq=39 ttl=64 time=15512 ms

64 bytes from 10.0.0.10: icmp_seq=40 ttl=64 time=14573 ms

64 bytes from 10.0.0.10: icmp_seq=41 ttl=64 time=13607 ms

64 bytes from 10.0.0.10: icmp_seq=42 ttl=64 time=12676 ms

64 bytes from 10.0.0.10: icmp_seq=43 ttl=64 time=11745 ms

64 bytes from 10.0.0.10: icmp_seq=44 ttl=64 time=10816 ms

64 bytes from 10.0.0.10: icmp_seq=45 ttl=64 time=9876 ms

64 bytes from 10.0.0.10: icmp_seq=46 ttl=64 time=8953 ms

64 bytes from 10.0.0.10: icmp_seq=47 ttl=64 time=8012 ms

64 bytes from 10.0.0.10: icmp_seq=48 ttl=64 time=7037 ms

64 bytes from 10.0.0.10: icmp_seq=49 ttl=64 time=6042 ms

64 bytes from 10.0.0.10: icmp_seq=50 ttl=64 time=5064 ms

64 bytes from 10.0.0.10: icmp_seq=51 ttl=64 time=4069 ms

64 bytes from 10.0.0.10: icmp_seq=52 ttl=64 time=3074 ms

64 bytes from 10.0.0.10: icmp_seq=53 ttl=64 time=2080 ms

64 bytes from 10.0.0.10: icmp_seq=54 ttl=64 time=1087 ms

64 bytes from 10.0.0.10: icmp_seq=55 ttl=64 time=102 ms

64 bytes from 10.0.0.10: icmp_seq=56 ttl=64 time=5.94 ms

64 bytes from 10.0.0.10: icmp_seq=57 ttl=64 time=5.57 ms

64 bytes from 10.0.0.10: icmp_seq=58 ttl=64 time=5.82 ms

64 bytes from 10.0.0.10: icmp_seq=59 ttl=64 time=5.49 ms

64 bytes from 10.0.0.10: icmp_seq=60 ttl=64 time=5.55 ms

^C

--- 10.0.0.10 ping statistics ---

60 packets transmitted, 60 received, 0% packet loss, time 59063ms

rtt min/avg/max/mdev = 5.498/13466.053/24565.805/8177.166 ms, pipe 25

root@node9:/# 



Aㅏ...

저기 중간에 점도 찍히지 않고 당당하게 5자리를 찍어주는 저 결과는 뭥미?

24205는 뭔가요? 저게 진정 와이파이 RTT인가여? 털썩...


각 컨테이너에서 아무 프로그램도 돌고 있지 않을 때는 이웃노드 간에 ping을 날리면 약 5ms가 되어야 정상인데, 보는 것처럼 데이터 패킷도 아닌 ICMP 패킷 하나가 바로 옆으로 가는 데 24초를 넘어섰다. ㄷㄷㄷ 저것도 계속 RTT가 커지기만 하길래 24초쯤 되는 상황에서 돌아가는 모든 Java 프로그램을 죽였더니, 한참이 지나고 나서야 ping이 정상으로 돌아온 것이다.


내가 Java 프로그램을 잘못 만들었구나 자책하려고 했지만, Host 머신에서 CPU 사용량을 확인해 보니 ns-3 프로세스가 혼자 97% ~ 110% 사이를 왔다갔다 하고 있었고, 정작 내가 개발한 Java 프로세스들은 별로 CPU를 차지하고 있지 않았다. (라즈베리파이2에서도 3-9% 수준이긴 했음)


일차적으로 생각해 본 원인은 ns-3 프로세스가 L2 이하를 시뮬레이션 시키고 있는데, 10개의 노드 각각이 라우팅을 위해서 Hello 패킷을 비롯한 컨트롤 패킷을 매 초마다 발생시키니까 싱글 코어만으로는 계산하는 양이 감당이 안돼서 응답이 늦어지는 바람에 ping이 20초를 넘어서는 저런 사단이 난 것 같았다.


아~망했어요 ㅠㅠ

나는 ns-3 코어가 적어도 100노드 정도의 scalability는 책임질 수 있을 거라 생각했는데... 이건 뭐 컨테이너가 제아무리 가벼워도 각자 발생시키는 패킷의 양이 늘어나면 ns-3 코어가 감당을 못하는 상황이라니...


현재까지는 ns-3에 멀티코어 활용하도록 고친다던지, 아예 컨테이너도 없이 real-world 프로그램을 직접 네트워크와 연동하는 방법(DCE라고 하는데... 결국 컨테이너로 해결을 못하면 이것도 공부해야 함...)은 아직 확인하지 못했다.


내가 ns-3에 멀티코어 활용 방법을 아직 몰라서 이런 것이라고 믿고 싶다. ㅜㅜ 

그런데 왠지 보니까 기본적으로 멀티코어를 활용하도록 설계했을 법도 한데 안한 점과 구글 검색(ns-3 multi core)에서 첫 페이지에서 그런 옵션을 켜는 법이라던지 하는 간단한 해결방법이 보이지 않는 것을 보면... 


야~신난다 @_@

대안으로 나온 것이 컨테이너도 없이 DCE라고 직접 프로그램 코드를 바로 실행하는 방법도 있지만 이건 C++만 된다고 한다. DCE에 Java 프로그램을 붙이는 방법이 있는지 찾아보고, 이마저도 없으면 쌩으로 Java를 모두 C++ 또는 파이썬으로 포팅하는 대규모 토건사업이 펼쳐지겠지 ㄹㅇㅁㄴㄹㅇㅁㄹㅁㅈ 일자리 창출 인정? =_=


정신줄 그만 놓고, 해결 방법을 찾아봐야겠다. ㅜㅜ


반응형
블로그 이미지

Bryan_

,
반응형

자바(Java)에서 Exception을 잘 다루면 여러 상황에 대한 대응력과 유연성을 높일 수 있지만, 예외처리에 대한 일관된 기준이나 잘 정리된 설계가 없으면 어떻게 처리(handling)할 지 막막해지기도 한다. 그래도 코딩하는 과정에서, 내가 만든 특정한 클래스를 참조해서 쓰는 다른 (작성자가 나일 수도 있고, 다른 개발자일 수도 있는) 클래스에게 이 예외상황만큼은 반드시 명시적으로 인지하고 특별하게 처리하도록 하고 싶으면 메쏘드 제목에서 throws 구문으로 예외를 caller에게 전달해야 한다.


그런데 특정한 예외를 caller에게 전달하려고 throws로 예외를 명시했는데도 caller 쪽에서 그 예외를 catch하지 못하는 경우가 있는데, 알고 보니 throw 하는 예외가 상속 관계에 의해서 부모 예외 타입으로 다른 곳에서 먼저 catch되는 바람에 caller 쪽에서 처리하지 못했던 것이었다.



구체적인 상황은 다음과 같다:


UDP Datagram Socket을 이용한 메세지 송수신 역할을 담당하는 클래스가 있는데, 여기에 타임아웃(timeout) 기능을 추가해서 특정한 메세지 전송에 대해서 응답을 받기 위해서 UDP Socket을 열되, 일정 시간 동안만 기다리도록 만들 필요가 생겼다. 찾아보니 Socket 클래스의 setSoTimeout 메쏘드를 시간값 파라미터와 함께 호출하면 해당 시간이 지난 뒤에 자동으로 SocketTimeoutException을 발생시킨다는 사실을 확인했다. 


그래서 아래와 같이 sendMessageAndGetReply(String ip, int port, String msg, int timeout) 메쏘드를 정의하고 throws SocketTimeoutException을 추가로 적어 주었는데, 그럼에도 불구하고 caller 쪽에서는 SocketTimeoutException을 catch할 수가 없었다.



public static String sendMessageAndGetReply(String ip, int port, String msg, int timeout) throws SocketTimeoutException {

String reply = null;

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

try {

DatagramSocket clientSocket = new DatagramSocket();

sendData = msg.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, InetAddress.getByName(ip), port);

clientSocket.send(sendPacket);

DatagramPacket recvPacket = new DatagramPacket(receiveData, receiveData.length);

clientSocket.setSoTimeout(timeout); // 추가로 타임아웃을 명시적으로 설정한 부분

clientSocket.receive(recvPacket);

reply = new String(recvPacket.getData());

clientSocket.close();

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (IOException e) {

e.printStackTrace();

}

return reply;

}



그런데 신기하게도 실행 화면에서는 SocketTimeoutException이 발생했다고 출력은 되는데, 정작 caller에서의 catch 구문은 실행되지 않았다.

코드의 다른 곳에서 해당 예외를 이미 처리했다는 의미인데, 알고 보니 sendMessageAndGetReply 메쏘드에서 catch (IOException e) 부분이 원인이었다. SocketTimeoutException은 java.io.InterruptedIOException을 extend한 자식 클래스이고, InterruptedIOException은 또한 IOException을 extend하고 있기 때문에, sendMessageAndGetReply가 해당 예외를 이미 처리해 버렸기 때문에, 제아무리 메쏘드 이름 옆에 throws로 명시해 두어도 throw가 되지 않았던 것이었다.


이것을 해결하기 위해서 결국 코드를 아래와 같이 고쳐야 했다. [2]


public static String sendMessageAndGetReply(String ip, int port, String msg, int timeout) throws SocketTimeoutException {

String reply = null;

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

try {

DatagramSocket clientSocket = new DatagramSocket();

sendData = msg.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, InetAddress.getByName(ip), port);

clientSocket.send(sendPacket);

DatagramPacket recvPacket = new DatagramPacket(receiveData, receiveData.length);

clientSocket.setSoTimeout(timeout); // 추가로 타임아웃을 명시적으로 설정한 부분

clientSocket.receive(recvPacket);

reply = new String(recvPacket.getData());

clientSocket.close();

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (IOException e) {

if(e instanceof SocketTimeoutException){

// 자식 클래스 예외를 특별하게 처리

throw new SocketTimeoutException();

}

e.printStackTrace();

}

return reply;

}


이렇게 했더니 콜 스택이 짧아지긴 했지만, 그래도 caller 쪽으로 Socket TimeoutException만큼은 확실하게 넘어가는 것을 확인할 수 있었다.


결론적으로, 당연한 얘기지만 예외를 처리할 때, throw하려는 예외가 혹시 해당 위치에 이미 존재하는 다른 catch 구문에 의해서 같이 처리되지는 않는지 상속 관계를 바탕으로 꼼꼼하게 확인할 필요가 있다.




<참고자료>

[1] http://stackoverflow.com/questions/27797451/i-cant-catch-sockettimeoutexception

[2] http://stackoverflow.com/questions/20532855/why-cant-i-handle-exception-e-with-try-catch-clause



반응형
블로그 이미지

Bryan_

,