현재  톰캣서버의 버젼이 7.0이 나왔지만 부득이하게 6.0버젼의 톰캣을 사용할일이 생겼다.
더군다나 새로 인스톨이 아닌 톰캣폴더자체를 복사해와 로컬에 셋팅을 하게되었다..음..-__-..

톰캣은 뭐 인스톨단계가 반드시 필요한건 아니기에 복사만으로 충분히 사용할수 있지만 한가지 아쉬운게
시스템트레이에 아이콘이 추가되지 않아 항상 시작 혹은 재시작 할경우 톰캣콘설창을 찾거나 폴더까지 가서 모니터링 실행명령어를 통해서만 일련의 작업을 진행하여 지속적인 불편함을 야기 했었다..

결국 참지 못하고 방법을 찾앗으니 아래와 같다..
참고로 필자의 톰캣경로는  D:\Tomcat 6.0 이다.

1.  단축아이콘 생성.
     - D:\Tomcat 6.0\bin\tomcat6w.exe 파일의 단축아이콘을 생성한다. (바탕화면이나 빠른실행 란에 생성)

2. 단축아이콘의 속성란 대상(T) 란에 톰캣실행명령어와 "//MS//Tomcat6" 추가  

 

//MS// 는  트레이아이콘에 추가하기 위한 옵션 명령어 - 상세는 여기로
Tomcat6 은 서비스에 추가된 서비스명이 되겠다.


여기까지 됐다면 이제 단축아이콘을 실행하면 하단 트레이아이콘에 톰캣 모니터링 아이콘이 실행된걸 확인할수있다.



 

처음 엔터프라이즈 응용프로그램 배포할때 사용했던 web.xml에 error-page 노드를 추가해야될일이 생겼다.
일반적으로 aaa.war/WEB-INF/ 폴더에 있는 web.xml을 수정하고 응용프로그램을 재시작햇으나 적용이 안되버리네.;;

결국 또 구글링 시작! ;;
알고봤더니 흔히 알고 있는 /WEB-INF 폴더밑에 web.xml말고 또 다른 폴더에 web.xml이 있더군.ㅜㅜ..
폴더 위치는 웹스피어 설치 경로에 따라 다르니 find로 해서 web.xml을 검색하면 된다.

보통 /webSphere/AppServer/profiles/폴더 아래에서  find ./ -name 'web.xml'  검색하면 되겟다.
그래서 나온 해당 응용프로그램 web.xml을 수정하고 재시작하니 적용이 된다.
혹시 배포경로(Deployment Manager)와 실제 응용프로그램 경로가 상이할경우엔 배포폴더에 있는 web.xml을 수정해야한다.
그렇지않다면 애플리케이션서버를 내렷다 올리면 다시 예전 버젼(배포폴더의 web.xml)으로 롤백되어버린다.;;;

원래 그런건지 아마도 WEB-INF 폴더 아래에 있는 web.xml은 최초 war배포할때에만 필요하고 그 담부터는
웹스피어 아래에 있는 web.xml을 사용하는가보다...

웹스피어에 JDBC 프로바이더를 추가해야되서 JAAS - J2C 인증 데이터에 해당 계정을 등록하구
데이터 소스를 등록하고 연결 테스트를 햇더니 아래와 같은 에러가 발생

다음 예외: java.sql.SQLException: null userid not supported
DSRA0010E: SQL State = null, Error Code = -99,999과(와) 함께 devNode01
노드에 있는 nodeagent 서버의 DB2 Winplus 데이터 소스에 대한 연결 테스트 조작에 실패했습니다.
JVM 로그 보기추가 세부사항의 경우

뭘까? 왜 JAAS - J2C 인증 데이터에 userid / passwd를 등록햇는데 null userid 에러가 나지?? 
여러 삽질을 하다 결국 구글링 시작..
결론은 JAAS - J2C 인증 데이터 새 계정을 등록하거나 수정하게 되면 JVM을 재가동하란다!!!
그래서 애플리케이션 서버를 재시작했더니 바로 연결 .뭔가 허무하지만 당연히 그랬어야 했다고 수긍해버렸다.-_-;;


참고 : http://www-01.ibm.com/support/docview.wss?uid=swg21235300

iframe으로 넣은 외부사이트의 쿠키를 읽어오게 할경우가 생긴다.
해당 iframe로 불러온 src 페이지 상단에 아래와 같은 P3P선언구문들을 추가하자.

PHP:
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');

ASP.NET:
HttpContext.Current.Response.AddHeader("p3p","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"");

JSP:
response.addHeader("P3P","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"")
 
[출처 : http://adamyoung.net/IE-Blocking-iFrame-Cookies]

개발하면서 놓치기 쉬운 코딩중에 WAS 병목현상을 유발할수도 있는 부분이다.

1) Java Programming

sycnronized block
위에서도 설명 했듯이 sychronized 메소드는 lock contention과 deadlock등의 문제를 유발할 수 있다. 꼭 필요한 경우에는 사용을 해야하지만, 이점을 고려해서 Coding해야한다.

String 연산

이미 많은 개발자들이 알고 있는 내용이겠지만 String 연산 특히 String연산중 “+” 연산은 CPU를 매우 많이 소모하게 되고 종종 slow down의 직접적인 원인이 되는 경우가 매우 많다.
String 보다는 가급적 StringBuffer를 사용하기 바란다.

Socket & file handling

Socket이나File Handling은 FD (File Descriptor)를 사용하게 되는데, 이는 유한적인 자원이기 때문에 사용후에 반드시 close명령을 이용해서 반환해야한다. 종종 close를 하지 않아서, FD가 모자르게 되는 경우가 많다.

2) Servlet/JSP Programming

JSP Buffer Size

Jsp 에서는 JSP의 출력 내용을 저장하는 buffer 사이즈를 지정할 수 있다.

<% page buffer=”12kb” %>

이 buffer size는 출력 내용을 buffering했다가 출력하는데, 만약에 쓰고자하는 내용이 Buffer size 보다 클 경우에는 여러번에 걸쳐서 socket write가 일어나기 때문에 performance에 영향을 줄 수 있으므로 가능하다면 buffersize를 화면에 뿌리는 내용의 크기를 예측해서 지정해주는것이 바람직하다. 반대로 너무 큰 버퍼를 지정해버리면 메모리가 불필요하게 낭비 될 수 있기 때문에 이점을 주의하기 바란다.

참고로 jsp page buffer size는 지정해주지 않는경우 default로 8K로 지정된다.

member variable

Servlet/JSP는 기본적으로 Multi Thread로 동작하기 때문에, Servlet과 JSP 내에서 선언된 멤버 변수들은 각 Thread간에 공유가 된다.
그래서 이 변수들을 read/write할경우에는 sychronized method로 구성해야 하는데, 이 synchronized는 속도 저하를 유발할 수 있기 때문에, member 변수로는 read 만 하는 객체를 사용하는게 좋다.

특히 Servlet이나 JSP에서 Data Base Connection을 멤버 변수로 선언하여 Thread간 공유하는 예가 있는데, 이는 별로 좋지 않은 프로그래밍 방법이고, 이런 형태의 패턴은 Servlet이 단 하나만 실행되거나 하는것과 같은 제약된 조건 아래에서만 사용해야 한다.

Out of Memory in file upload

JSP에서 File upload control을 사용하는 경우가 많다. 이 control을 구현하는 과정에서 upload되는 파일 내용을 몽땅 메모리에 저장했다가 업로드가 끝나면 한꺼번에 file에 writing하는 경우가 있는데, 이는 큰 사이즈의 파일을 업로드할때, 파일 사이즈만큼의 메모리 용량을 요구하기 때문에, 자칫하면 Out Of Memory 에러를 발생 시킬 수 있다.
File upload는 buffer를 만들어서 읽고, 파일에 쓰는 작업을 병행하도록 해야한다.

3) JDBC Programming

Connection Leak

JDBC Programming에서 가장 대표적으로 발생되는 문제가 Connection Leak이다. Database Connection을 사용한후에 close않아서 생기는 문제인데,Exception이 발생하였을때도 반드시 Connection을 close하도록 해줘야한다.


<그림. Connection close의 올바른 예>


Out of memory in Big size query result

SQL문장을 Query하고 나오는 resultset을 사용할때, 모든 resultset의 결과를 Vector나 hashtable등을 이용해서 메모리에 저장해놓는 경우가 있다. 이런 경우에는 평소에는 문제가 없지만, SQL Query의 결과가 10만건이 넘는것과 같은 대용량일때 이 모든 데이타를 메모리 상에 저장할려면 Out Of Memory가 나온다.
Query의 결과값을 처리할때는 ResultSet을 직접 리턴받아서 사용하는것이 메모리 활용면에서 좀더 바람직하다.

Close stmt & resultset

JDBC에서 Resultset이나 Statement 객체는 기본적으로 Connection을 close하게 되면 자동으로 닫히게 된다. 그러나 WAS나 Servlet Container의 경우에는 성능향상을 위해서 Connection Pooling 기법을 이용해서 Connection을 관리하기 때문에 Connection Pooling에서 Connection을 close하는것은 실제로 close하는것이 아니라 Pool에 반환하는 과정이기 때문에 해당 Connection에 연계되어 사용되고 있는 Statement나 ResultSet이 닫히지 않는다.

Connection Pooling에서 Statement와 ResultSet을 사용후에 닫아주지 않으면 Oracle에서 too many open cursor와 같은 에러가 나오게된다. (Statement는 DB의 Cursor와 mapping이 된다.)

출처 : http://www.j2eestudy.co.kr/lecture/lecture_read.jsp?table=j2ee&db=lecture0201_1&id=24
이번에 했던 프로젝트에서 개발기는 톰캣환경이여서web.xml에서 dtd버전이 2.3버젼이였는데..리얼환경의 웹로직 6.1버젼에선 dtd버젼이 2.2라네...-_-;;..

2.2 버젼 url : http://java.sun.com/j2ee/dtds/web-app_2_2.dtd
2.3 버젼 url : http://java.sun.com/dtd/web-app_2_3.dtd
2.4 버젼 url : http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd

차이가 얼마나 날까 싶어 무시하고 리얼에 올렷다가 낭패를 봤다..
DTD 2.3버젼 Element중에 filter가 있는데 이게 2.2버젼에 없다..-_-
이말은 한글처리를 위해서 web.xml에서 filter-mapping 으로 간단히 설정만 해줫던걸 2.2에서는 최악의 경우 jsp, servlet 에서 일일이 노가다를 해줘야 될수도 있다..

여러 방법이 있겠지만 일단 다른 방법으로 해결은 봣지만 아무튼 버젼차이에서 오는 이런문제는 정말 난감하다..
(다행히 request를 받는 공통 Hashtable이 있어서 새로 상속받아 get에서 한글 인코딩처리를 함으로 간단히 해결했다.;;;)

차후에는 리얼서버의 스펙을 좀더 자세하게 볼 필요가 있게 해줘 다행이다..-_-;

+ Recent posts