JEUS

JEUS Web Engine 안내서 JEUS v7.0 Fix#1 Copyright 2013 TmaxSoft Co., Ltd. All Rights Reserved.

Copyright Notice Copyright 2013 TmaxSoft Co., Ltd. All Rights Reserved. 대한민국경기도성남시분당구서현동 272-6 우 ) 463-824 Restricted Rights Legend All TmaxSoft Software (JEUS ) and documents are protected by copyright laws and international convention. TmaxSoft software and documents are made available under the terms of the TmaxSoft License Agreement and may only be used or copied in accordance with the terms of this agreement. No part of this document may be transmitted, copied, deployed, or reproduced in any form or by any means, electronic, mechanical, or optical, without the prior written consent of TmaxSoft Co., Ltd. 이소프트웨어 (JEUS ) 사용설명서의내용과프로그램은저작권법과국제조약에의해서보호받고있습니다. 사용설명서의내용과여기에설명된프로그램은 TmaxSoft Co., Ltd. 와의사용권계약하에서만사용이가능하며, 사용권계약을준수하는경우에만사용또는복제할수있습니다. 이사용설명서의전부또는일부분을 TmaxSoft의사전서면동의없이전자, 기계, 녹음등의수단을사용하여전송, 복제, 배포, 2차적저작물작성등의행위를하여서는안됩니다. Trademarks JEUS is registered trademark of TmaxSoft Co., Ltd. Other products, titles or services may be registered trademarks of their respective companies. JEUS 는 TmaxSoft Co., Ltd. 의등록상표입니다. 기타모든제품들과회사이름은각각해당소유주의상표로서참조용으로만사용됩니다. Open Source Software Notice Some modules or files of this product are subject to the terms of the following licenses. : APACHE2.0, CDDL1.0, EDL1.0, OPEN SYMPHONY SOFTWARE1.1, TRILEAD-SSH2, Bouncy Castle, BSD, MIT, SIL OPEN FONT1.1 Detailed Information related to the license can be found in the following directory : ${INSTALL_PATH}/lib/licenses 본제품의일부파일또는모듈은다음의라이선스를준수합니다. : APACHE2.0, CDDL1.0, EDL1.0, OPEN SYM PHONY SOFTWARE1.1, TRILEAD-SSH2, Bouncy Castle, BSD, MIT, SIL OPEN FONT1.1 관련상세한정보는제품의다음의디렉터리에기재된사항을참고해주십시오. : ${INSTALL_PATH}/lib/licenses 안내서정보안내서제목 : JEUS Web Engine 안내서발행일 : 2013-04-30 소프트웨어버전 : JEUS v7.0 Fix#1 안내서버전 : v2.1.2

내용목차 안내서에대하여... xiii 제1장 웹엔진... 1 1.1. 개요... 1 1.2. 구성요소... 1 1.3. 주요기능... 3 1.4. 관리도구... 5 1.4.1. 도구종류... 5 1.4.2. 제어와모니터링... 5 1.5. 디렉터리구조... 8 1.6. 환경설정... 10 1.6.1. XML 설정파일... 13 1.6.2. 모니터링설정... 15 1.6.3. 기본오류페이지설정... 17 1.6.4. 오류발생의경우 Stack Trace 첨부설정... 19 1.6.5. 인코딩설정... 21 1.6.6. JSP 엔진설정... 24 1.6.7. 응답헤더설정... 25 1.6.8. 쿠키정책설정... 26 1.6.9. 세션설정... 28 1.6.10. 로그설정... 29 1.6.11. Async Servlet 타임아웃처리설정... 42 1.6.12. 웹엔진레벨의프로퍼티설정... 44 1.6.13. 웹공격대응설정... 46 1.7. 웹엔진튜닝... 47 제2장 웹커넥션관리... 49 2.1. 개요... 49 2.2. 구성요소... 50 2.2.1. 리스너... 50 2.2.2. 커넥터... 51 2.2.3. Worker Thread Pool... 52 2.3. 웹커넥션설정... 52 2.3.1. 리스너공통설정... 53 2.3.2. AJP 리스너설정... 56 2.3.3. HTTP 리스너설정... 64 2.3.4. TCP 리스너설정... 68 2.3.5. WebtoB 커넥터설정... 72 2.3.6. Tmax 커넥터설정... 78 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통보 )... 85 2.4. 부하분산을위한웹서버설정... 87 2.4.1. 부하분산구조... 87 JEUS iii

2.4.2. Apache 웹서버... 88 2.4.3. IIS 웹서버및 Iplanet 웹서버설정... 91 2.4.4. WebtoB와의부하분산설정... 92 2.5. TCP 리스너사용... 94 2.5.1. 맞춤통신프로토콜정의... 95 2.5.2. Dispatcher Config Class 구현... 95 2.5.3. TCP 핸들러구현... 98 2.5.4. 맞춤프로토콜코드를위한 TCP 리스너설정... 101 2.5.5. TCP 클라이언트구현... 101 2.5.6. TCP 클라이언트컴파일과실행... 103 2.6. 커넥터제어... 104 2.7. 리스너튜닝... 107 제3장 웹컨텍스트... 109 3.1. 개요... 109 3.2. 기본구조... 109 3.2.1. 웹컨텍스트콘텐츠... 109 3.2.2. 웹컨텍스트내부구조 (WAR 파일구조 )... 110 3.3. 웹컨텍스트 Deploy... 111 3.3.1. jeus-web-dd.xml 설정... 111 3.3.2. 웹컨텍스트 Redeploy(Graceful Redeploy)... 114 3.3.3. Shared Library Reference 추가... 114 3.3.4. 호환성을위한웹컨텍스트레벨의옵션설정... 116 3.3.5. 부가기능사용을위한설정... 117 3.3.6. 웹보안설정... 118 3.3.7. 보안 Role 매핑... 120 3.3.8. Symbolic Reference 매핑... 121 3.4. 웹컨텍스트모니터링... 123 3.5. 웹컨텍스트제어... 126 3.5.1. 웹컨텍스트리로드... 126 3.5.2. 웹컨텍스트의비동기요청에대한 Thread Pool 모니터링... 128 3.5.3. 웹컨텍스트중지... 130 3.5.4. 웹컨텍스트리로드... 130 3.6. 웹컨텍스트튜닝... 131 3.7. 비동기식처리프로그래밍가이드... 131 3.7.1. Servlet 표준에따른주의사항... 131 3.7.2. 기타주의사항... 136 제4장 JSP 엔진... 137 4.1. 개요... 137 4.2. Apache Tomcat Jasper... 138 4.3. JSP 엔진의기능... 139 4.3.1. JSP 리로딩... 139 4.3.2. JSP 프리컴파일... 140 iv JEUS Web Engine 안내서

4.3.3. JSP Graceful Reloading 기능... 140 4.3.4. 메모리에서의 JSP 컴파일및실행기능... 141 4.4. JSP 엔진설정... 142 4.4.1. 웹엔진레벨에서의설정... 142 4.4.2. jeus-web-dd.xml 설정... 145 4.4.3. JSP 하위호환성을위한웹컨텍스트레벨의옵션설정... 146 제5장 가상호스트... 149 5.1. 개요... 149 5.2. 웹엔진과가상호스트... 149 5.2.1. ServletContext 객체와가상호스트... 151 5.3. 가상호스트를통한웹컨텍스트요청... 151 5.3.1. URL 매칭예제... 151 5.3.2. URL 매칭순서... 152 5.4. 가상호스트설정... 153 5.4.1. 추가... 153 5.4.2. 수정... 155 5.4.3. 삭제... 159 제6장 JEUS WebCache... 161 6.1. 개요... 161 6.2. JSP Caching... 161 6.2.1. 기본내용... 162 6.2.2. <cache> 태그... 163 6.2.3. <jeus:cache> 사용예... 166 6.2.4. flush 기능사용... 166 6.2.5. refresh 기능사용... 167 6.3. HTTP Response Caching... 167 6.3.1. 필터설정... 168 제7장 Reverse Proxy... 171 7.1. 개요... 171 7.1.1. 적용예시... 171 7.2. 사용방법... 172 7.2.1. Proxy 서버설정... 172 7.2.2. Context-path 설정... 174 7.2.3. Proxy 필터설정... 174 7.2.4. Deploy... 176 7.3. 설정예... 176 제8장 클래스동적반영... 179 8.1. 개요... 179 8.2. 기본설정및동작... 180 8.2.1. 서버설정... 181 8.2.2. 애플리케이션설정... 181 JEUS v

8.2.3. 설정에따른동작... 181 8.2.4. JEUS HotSwap으로지원가능한애플리케이션및변환... 182 8.2.5. JEUS HotSwap 제약사항... 185 제9장 따라하기... 187 용어해설... 191 색인... 195 vi JEUS Web Engine 안내서

그림목차 [ 그림 1.1] 웹엔진의구성요소... 1 [ 그림 1.2] 웹엔진모니터링 - 메뉴이동... 6 [ 그림 1.3] server1 웹엔진모니터링 - 정보조회... 7 [ 그림 1.4] JEUS 디렉터리구조에서의웹엔진... 8 [ 그림 1.5] 설정적용 - Activate Changes... 11 [ 그림 1.6] 고급선택사항... 12 [ 그림 1.7] 모니터링 - 설정메뉴이동... 15 [ 그림 1.8] 모니터링 - 설정... 16 [ 그림 1.9] 모니터링 - 설정적용결과... 17 [ 그림 1.10] 기본오류페이지 - 설정... 18 [ 그림 1.11] 기본오류페이지 - 설정적용결과... 19 [ 그림 1.12] 오류발생시 Stack Trace 첨부 - 설정... 20 [ 그림 1.13] 오류발생시 Stack Trace 첨부 - 설정적용결과... 21 [ 그림 1.14] 웹엔진인코딩 - 설정... 23 [ 그림 1.15] 웹엔진인코딩 - 설정적용결과... 24 [ 그림 1.16] 웹엔진응답헤더 - 설정... 25 [ 그림 1.17] 웹엔진응답헤더 - 설정적용... 26 [ 그림 1.18] 웹엔진쿠키정책 - 설정... 27 [ 그림 1.19] 웹엔진쿠키정책 - 설정적용결과... 28 [ 그림 1.20] 웹엔진액세스로그 - 설정메뉴이동... 30 [ 그림 1.21] 웹엔진액세스로그 - 설정... 31 [ 그림 1.22] 웹엔진액세스로그 - 설정적용결과... 32 [ 그림 1.23] 유저로그 - 설정... 37 [ 그림 1.24] 유저로그 - 핸들러추가... 39 [ 그림 1.25] 유저로그 - 핸들러설정... 39 [ 그림 1.26] 유저로그 - 핸들러추가확인... 40 [ 그림 1.27] 유저로그 - 핸들러추가적용결과... 41 [ 그림 1.28] Async Servlet 타임아웃처리 - Async Timeout Min Threads 설정... 42 [ 그림 1.29] Async Servlet 타임아웃처리 - Async Timeout Min Threads 설정적용결과... 43 [ 그림 1.30] 웹엔진프로퍼티 - 설정... 44 [ 그림 1.31] 웹엔진프로퍼티 - 설정적용결과... 45 [ 그림 1.32] 웹공격대응 - 메뉴이동... 47 [ 그림 1.33] 웹공격대응 - 고급선택사항설정... 47 [ 그림 2.1] 웹엔진의리스너... 50 [ 그림 2.2] 웹엔진의커넥터... 51 [ 그림 2.3] AJP 리스너추가및수정 - 추가... 57 [ 그림 2.4] AJP 리스너추가및수정 - 일반설정... 57 [ 그림 2.5] AJP 리스너추가및수정 - Thread Pool 설정... 58 [ 그림 2.6] AJP 리스너추가및수정 - Thread State Notify설정... 74 [ 그림 2.7] AJP 리스너추가및수정 - 고급선택사항설정설정... 59 JEUS vii

[ 그림 2.8] AJP 리스너추가및수정 - 설정확인... 60 [ 그림 2.9] AJP 리스너추가및수정 - 설정적용결과... 60 [ 그림 2.10] AJP 리스너삭제 - 메뉴이동... 61 [ 그림 2.11] AJP 리스너삭제 - 선택... 62 [ 그림 2.12] AJP 리스너삭제 - 삭제확인... 62 [ 그림 2.13] HTTP 리스너추가및수정 - 일반설정... 64 [ 그림 2.14] HTTP 리스너추가및수정 - 고급선택사항설정... 65 [ 그림 2.15] HTTP 리스너추가및수정 - 추가확인... 66 [ 그림 2.16] HTTP 리스너삭제 - 선택... 67 [ 그림 2.17] HTTP 리스너삭제 - 삭제확인... 67 [ 그림 2.18] TCP 리스너추가및수정 - 일반설정... 68 [ 그림 2.19] TCP 리스너추가및수정 - 고급선택사항설정... 69 [ 그림 2.20] TCP 리스너추가및수정 - 추가확인... 70 [ 그림 2.21] TCP 리스너삭제 - 선택... 71 [ 그림 2.22] TCP 리스너삭제 - 삭제확인... 71 [ 그림 2.23] WebtoB 커넥터추가및수정 - 기본설정... 72 [ 그림 2.24] WebtoB 커넥터추가및수정 - 연결설정... 73 [ 그림 2.25] WebtoB 커넥터추가및수정 - Thread Pool 설정... 73 [ 그림 2.26] WebtoB 커넥터추가및수정 - Thread State Notify 설정... 74 [ 그림 2.27] WebtoB 커넥터추가및수정 - 고급선택사항설정... 75 [ 그림 2.28] WebtoB 커넥터추가및수정 - 추가확인... 76 [ 그림 2.29] WebtoB 커넥터삭제 - 선택... 77 [ 그림 2.30] WebtoB 커넥터삭제 - 삭제확인... 77 [ 그림 2.31] Tmax 커넥터추가및수정 - 기본설정... 79 [ 그림 2.32] Tmax 커넥터추가및수정 - 고급선택사항설정... 81 [ 그림 2.33] Tmax 커넥터추가및수정 - 추가확인... 82 [ 그림 2.34] Tmax 커넥터삭제 - 선택... 83 [ 그림 2.35] Tmax 커넥터삭제 - 삭제확인... 83 [ 그림 2.36] Tmax 커넥터삭제 - 삭제적용결과... 84 [ 그림 2.37] 자동 Thread Pool 관리설정 - Thread State Notify 설정... 86 [ 그림 2.38] 소규모웹사이트에서의부하분산구조... 88 [ 그림 2.39] 부하분산서버구조 - 2대의 WebtoB가각각 2대의웹엔진에연결된경우... 92 [ 그림 2.40] WebtoB 커넥터설정상태... 93 [ 그림 2.41] 커넥터제어 - 웹커넥션조회... 105 [ 그림 2.42] 커넥터제어 - WebtoB 커넥터 suspend 수행... 105 [ 그림 2.43] 커넥터제어 - WebtoB 커넥터 resume 수행... 106 [ 그림 3.1] WAR 파일구조... 110 [ 그림 3.2] 웹컨텍스트모니터링 - 애플리케이션조회... 123 [ 그림 3.3] 웹컨텍스트모니터링 - 웹애플리케이션선택... 124 [ 그림 3.4] 웹컨텍스트모니터링 - 웹애플리케이션세부정보조회... 125 [ 그림 3.5] 웹애플리케이션 reload... 127 [ 그림 3.6] 웹애플리케이션 thread-info... 129 [ 그림 4.1] JSP 엔진설정 - 메뉴이동... 143 viii JEUS Web Engine 안내서

[ 그림 4.2] JSP 엔진설정 - 기본정보설정... 143 [ 그림 4.3] JSP 엔진설정 - 설정적용결과... 145 [ 그림 5.1] 가상호스트의이용패턴... 150 [ 그림 5.2] 웹엔진과가상호스트, 웹컨텍스트간의유효한관계의예... 151 [ 그림 5.3] 가상호스트추가 - 메뉴이동... 153 [ 그림 5.4] 가상호스트추가 - 기본정보설정... 154 [ 그림 5.5] 가상호스트추가 - 추가적용결과... 155 [ 그림 5.6] 가상호스트수정 - 기본정보수정... 156 [ 그림 5.7] 가상호스트수정 - Access Log 추가설정... 157 [ 그림 5.8] 가상호스트수정 - 액세스로그추가적용결과... 158 [ 그림 5.9] 가상호스트삭제 - 삭제확인... 159 [ 그림 6.1] 엔트리 Caching에사용되는자료구조... 162 JEUS ix

예목차 [ 예 1.1] XML 헤더 : <<domain.xml>>... 14 [ 예 1.2] XML 헤더 : <<jeus-web-dd.xml>>... 14 [ 예 1.3] XML 헤더 : <<web.xml >>... 14 [ 예 1.4] jeus.servlet.logger.accessloggerfilter 인터페이스의상세내용... 34 [ 예 1.5] 필터클래스정의예제... 35 [ 예 2.1] mod_jk 설정파일예제 : <<workers.properties>>... 89 [ 예 2.2] Apache에 mod_jk 설정예제 : <<httpd.conf>>... 91 [ 예 2.3] WebtoB 설정예 : <<http.m>>... 93 [ 예 2.4] TCPDispatcherConfig 구현예 : <<SampleConfig.java>>... 96 [ 예 2.5] TCPServlet 구현예 : <<SampleServlet.java>>... 98 [ 예 2.6] TCP 핸들러 DD : <<web.xml>>... 101 [ 예 2.7] TCP 클라이언트구현예 : <<Client.java>>... 102 [ 예 3.1] 웹컨텍스트설정파일 : <<jeus-web-dd.xml>>... 111 [ 예 3.2] Shared Library Reference 추가 : <<libraries.xml>>... 114 [ 예 3.3] 정적리소스를처리하는서블릿매핑 : <<web.xml>>... 117 [ 예 3.4] mvc:default-servlet-handler를위한 ResourceServlet 등록 : <<web.xml>>... 118 [ 예 3.5] mvc:default-servlet-handler 설정... 118 [ 예 3.6] Redirect Location 보안설정인터페이스 : <<RedirectStrategy>>... 118 [ 예 3.7] Redirect Location 보안설정구현예 : <<RejectCrlfRedirectStrategy>>... 119 [ 예 3.8] Redirect Location 보안설정 : <<jeus-web-dd.xml>>... 119 [ 예 3.9] 보안 Role 매핑 : <<web.xml>>... 120 [ 예 3.10] 보안 Role 매핑 : <<jeus-web-dd.xml>>... 120 [ 예 3.11] Symbolc Reference 매핑 : <<web.xml>>... 121 [ 예 3.12] Symbolc Reference 매핑 : <<jeus-web-dd.xml>>... 122 [ 예 3.13] <async-config> 설정 : <<jeus-web-dd.xml>>... 128 [ 예 3.14] 잘못된비동기식처리프로그래밍작성예 (1)... 132 [ 예 3.15] 잘못된비동기식처리프로그래밍작성예 (2)... 133 [ 예 3.16] 잘못된비동기식처리프로그래밍작성예 (3)... 134 [ 예 4.1] 웹컨텍스트설정파일 : <<jeus-web-dd.xml>>... 145 [ 예 4.2] JSP 하위호환성을위한웹컨텍스트설정 : <<jeus-web-dd.xml>>... 147 [ 예 6.1] <cache> 태그설정 : <<jeuscache.tld>>... 163 [ 예 6.2] <jeus:cache> 사용예제 : <<cache.jsp>>... 166 [ 예 6.3] jsp:inclue를이용한 <jeus:cache> 사용예제 : <<main.jsp>>... 166 [ 예 6.4] 필터설정 : <<web.xml>>... 168 [ 예 7.1] data.xml의 dtd : <<proxy-config.dtd>>... 173 [ 예 7.2] Proxy 필터만사용할경우 : <<web.xml>>... 174 [ 예 7.3] Proxy 필터와 Rewrite 필터를함께사용할경우 : <<web.xml>>... 175 [ 예 8.1] Jeus HotSwap설정 : <<startdomainadminserver>>... 181 [ 예 8.2] Jeus HotSwap 설정 : <<startmanagedserver>>... 181 [ 예 8.3] Auto Reload 설정 : <<jeus-web-dd.xml>>... 181 JEUS xi

안내서에대하여 안내서의대상 본안내서는 JEUS 웹엔진의사용법, 웹엔진구성하는요소들의개념및컨트롤및모니터링방법들에대해서설명하는안내서로 Java EE 웹애플리케이션을 deploy하고관리하는시스템관리자또는웹애플리케이션개발자를대상으로한다. 안내서의전제조건 본안내서를원활하게이해하기위해서는다음과같은사항을미리알고있어야한다. Java EE, Servlet, JSP 표준 웹애플리케이션패키징과 Deploy에관한지식 JEUS의기본구조 참고 더자세한정보가필요하다면 "JEUS Server 안내서 " 를참고하고, 필요에따라 "JEUS Web Service 안내서 " 를참고한다. 안내서의제한조건 본안내서에서는 JEUS 웹엔진에관련된사항들에대해서만설명하고 Java EE 표준에대한사항들은언 급하지않는다. 참고 자세한내용은 http://www.oracle.com/technetwork/java/index.html 을참고한다. 안내서에대하여 xiii

안내서구성 본안내서는다음과같이총 9개의장으로구성되어있다. 제1장웹엔진 JEUS 웹엔진의주요기능, 기본적인설정방법에대해설명한다. 제2장웹커넥션관리 웹엔진에서제공하는리스너또는커넥터의관리및설정방법등에대해설명한다. 제3장웹컨텍스트 JEUS 웹애플리케이션을패키징하는방법과이를 JEUS 웹엔진에 deploy하고모니터링하는방법에대해설명한다. 제4장 JSP 엔진 JSP 엔진의개념과기능, 설정방법에대해설명한다. 제5장가상호스트 가상호스트의사용목적, 규칙및설정방법등에대해설명한다. 제6장 JEUS WebCache 웹애플리케이션의성능향상을위한 JEUS WebCache를적용하는방법에대해설명한다. 제7장 Reverse Proxy 웹애플리케이션의성능향상을위한 Reverse Proxy의기본개념과사용방법을예제를통해설명한다. 제8장클래스동적반영 웹애플리케이션의개발속도향상을위한 Servlet Auto Reload 기능에대해설명한다. 제9장따라하기 JEUS를간단하게체험해볼수있도록예제를설명한다. xiv JEUS Web Engine 안내서

안내서규약 표기 <<AaBbCc123>> <Ctrl>+C [Button] 진하게 " "( 따옴표 ) ' 입력항목 ' 하이퍼링크 > +---- ---- 참고주의 [ 그림 1.1] [ 표 1.1] AaBbCc123 의미프로그램소스코드의파일명 Ctrl과 C를동시에누름 GUI의버튼또는메뉴이름강조다른관련안내서또는안내서내의다른장및절언급화면 UI에서입력항목에대한설명메일계정, 웹사이트메뉴의진행순서하위디렉터리또는파일있음하위디렉터리또는파일없음참고또는주의사항주의할사항그림이름표이름 Java 코드, XML 문서 [ command argument ] < xyz > 옵션파라미터 < 와 > 사이의내용이실제값으로변경됨선택사항. 예 ) A B: A나 B 중하나파라미터등이반복되어서나옴 안내서에대하여 xv

시스템사용환경 본안내서의모든예제와환경구성은 UNIX의스타일에준하여작성되어 Microsoft Windows ( 이하 Windows) 와같이다른환경에서작업하는경우몇가지사항을고려해야한다. 예를들어경로구분자의경우 UNIX 스타일인 / 를 Windows 스타일인 \ 로바꿔서사용한다. 또한환경변수도 Windows 스타일로변경해서사용하면된다. 문서의내용은 Java 표준을고려해서작성했기때문에대부분의내용은동일하게적용된다. xvi JEUS Web Engine 안내서

관련안내서 안내서 JEUS Server 안내서 JEUS Web Service 안내서 JEUS WebAdmin 안내서 JEUS 세션관리안내서 JEUS Reference Book 설명 JEUS 서버에대한설명과시스템관리를위한방법을기술한안내서이다. JEUS 내의웹서비스에대해기술한안내서이다. JEUS의웹관리툴인 WebAdmin을사용한 JEUS의설정및제어, 모니터링, 클러스터링, 리소스설정및관리에대해기술한안내서이다. JEUS에서운용하는 Session Manager, Session Server의설정및관리에대한기술안내서이다. JEUS를사용할때도움이되는 Reference를기술한안내서이다. 참고자료 Java EE 6 표준 Servlet 3.0 표준 JSP 2.2 표준 (JSR 245 Maintenance Release) EL 2.2 표준 (JSR 245 Maintenance Release) JEUS_HOME/docs/reference/schema/index.html에서 XML Reference domain.xml의웹 / 서블릿엔진 domain.xml의웹엔진내의인코딩 domain.xml의웹엔진내부 JSP 엔진 domain.xml의웹엔진내의웹연결 ( 웹리스너, 웹서버연결 ) domain.xml의웹엔진내세션 domain.xml의웹엔진내의가상호스트 (Virtual Host) 웹엔진의설정에대해자세히설명한다. JEUS_HOME/docs/reference/schema/index.html에서 jeus-web-dd.xml XML Reference JEUS Context( 웹애플리케이션 ) Deployment Descriptor에대해자세히설명한다. JEUS_HOME/docs/api/jeusapi/index.html에서 Webcontainer Tcp Listener API Reference TCP Listener를사용한통신프로토콜을구현하기위한 API( 제2장웹커넥션관리 에설명됨 ) 에대해설명한다. 안내서에대하여 xvii

연락처 Korea TmaxSoft Co., Ltd 272-6, Seohyeon-dong, Bundang-gu, Seongnam-si, Gyeonggi-do, 463-824 South Korea Tel: +82-31-8018-1000 Fax: +82-31-8018-1115 Email: info@tmax.co.kr Web (Korean): http://www.tmax.co.kr 기술지원 : http://technet.tmaxsoft.com USA TmaxSoft, Inc. 560 Sylvan Avenue Englewood Cliffs, NJ 07632 U.S.A Tel: +1-201-567-8266 Fax: +1-201-567-7339 Email: info@tmaxsoft.com Web (English): http://www.tmaxsoft.com Japan TmaxSoft Japan Co., Ltd. 5F Sanko Bldg, 3-12-16 Mita, Minato-Ku, Tokyo, 108-0073 Japan Tel: +81-3-5765-2550 Fax: +81-3-5765-2567 Email: info@tmaxsoft.co.jp Web (Japanese): http://www.tmaxsoft.co.jp xviii JEUS Web Engine 안내서

China TmaxSoft China Co., Ltd. Beijing Silver Tower, RM 1508, 2# North Rd Dong San Huan, Chaoyang District, Beijing, China, 100027 China Tel: +86-10-6410-6145~8 Fax: +86-10-6410-6144 Email: info.cn@tmaxsoft.com Web (Chinese): http://www.tmaxsoft.com.cn 안내서에대하여 xix

제 1 장웹엔진 본장에서는 JEUS 웹엔진의구성요소, 주요기능, 기본적인설정방법에대해설명한다. 1.1. 개요 Java EE 웹애플리케이션 ( 이하웹애플리케이션 ) 은사용자에게동적으로웹콘텐츠를제공하기위한서블릿 (Servlet), JSP와 HTML 파일같은정적리소스들로구성되어있다. JEUS는이러한웹애플리케이션을효율적으로관리하는웹엔진을제공한다. 본장에서는 JEUS 웹엔진에대하여소개하고, 운영환경에서제어하고모니터링하는방법을설명한다. 1.2. 구성요소 본절에서는웹엔진의구성요소와웹엔진과연관된외부요소들에대해설명한다. 웹엔진은 Java EE, 서블릿, JSP, 그리고 EL 표준에따르는웹애플리케이션을관리하고이를서비스하는개체이다. 서블릿과 JSP와같은동적리소스뿐만아니라 HTML과같은정적리소스도서비스할수있다. 참고 웹엔진은웹컨테이너 (Web Container) 또는서블릿엔진 (Servlet Engine) 이라고부르기도한다. [ 그림 1.1] 웹엔진의구성요소 JEUS Web Engine Client A Web Server A Web connections Virtual Host A Context/Web app A Default Virtual Host Context/Web app B Monitoring thread Session Management Service Misc. Engine Settings JEUS Web Engine (of another JEUS Server) Client B Web connections Default Virtual Host Context/Web app B Monitoring thread Session Management Service Client C Web Server B Misc. Engine Settings 제 1 장웹엔진 1

주요구성요소들은다음과같다. Web Connections Web Connections( 이하웹커넥션 ) 은클라이언트, 웹서버또는기타다른서버들과웹엔진이연결되기위한요소이다. 여러개의웹서버와웹엔진들이서로연결되어성능과안정성을향상시킨커다란클러스터링으로구성할수있다. 이에대한내용은 제2장웹커넥션관리 를참고한다. 가상호스트클라이언트가서로다른호스트이름을지정해서호출했을때, 각호스트이름에매핑된웹애플리케이션을호출할수있도록제공하는가상의그룹이다. 웹애플리케이션을특정가상호스트를지정해서 deploy할수있다. 자세한내용은 제5장가상호스트 를참고한다. Web Context( 웹애플리케이션 ) 서블릿, JSP 표준을따르는웹애플리케이션을웹엔진에 deploy하면이에대한 Web Context( 이하웹컨텍스트 ) 를생성한다. 웹애플리케이션은일반적으로 WAR(Web ARchive) 형태로패키징하며, 웹엔진내의가상호스트에 deploy된다. 자세한내용은 제3장웹컨텍스트 를참고한다. 모니터링 Thread 웹엔진의여러구성요소들을감시하는역할을한다. 자세한내용은 1.3. 주요기능 의모니터링을참고한다. 세션관리서비스분산된환경에서클라이언트의세션을관리하고이를여러웹엔진에서사용가능한환경을제공한다. 자세한내용은 JEUS 세션관리안내서 의 제1장세션트래킹 (Session Tracking) 을참고한다. 기타웹엔진설정웹엔진에공통적으로적용되는설정들이다. 기본오류페이지, 인코딩설정, JSP 엔진설정, 응답헤더설정등이이에해당된다. 참고 JEUS 6 까지존재했던 Context Group( 이하컨텍스트그룹 ) 이 JEUS 7 에서는존재하지않는다. 컨텍 스트그룹의대부분의기능은웹엔진에서대신한다. 웹엔진과연관된외부요소들은다음과같다. 클라이언트 JEUS 웹엔진으로서비스를요청한다. HTTP 기반의웹브라우저가일반적이다. 웹서버클라이언트의 HTTP 요청을받아서필요한경우에 JEUS 웹엔진에전달한다. JEUS 웹엔진은단독으로 HTTP 클라이언트의요청을처리하기보다는웹서버 (Web Server) 와의조합으로사용되는경우가일반적이다. 자세한내용은 제2장웹커넥션관리 를참고한다. 2 JEUS Web Engine 안내서

1.3. 주요기능 웹엔진의주요기능은다음과같다. 웹애플리케이션관리웹엔진은 Java EE 표준을준수하는웹애플리케이션의 Deploy, Undeploy 및일시서비스정지기능을제공한다. 그외에도서비스의중단없이 Redeploy하는기능을지원한다. 이에관한자세한내용은 제 3장웹컨텍스트 를참고한다. 모니터링모니터링은웹엔진의자원들의상태를감시하고문제가발생했을때대응하기위한기능이다. 크게 3 가지타입의모니터링이존재한다. 각각의설정에대한자세한내용은 1.6.2. 모니터링설정 을참고한다. Thread Pool 모니터링웹커넥션별로가지고있는 Thread Pool을모니터링한다. 자세한내용은 제2장웹커넥션관리 를참고한다. 클래스로더모니터링웹애플리케이션들의서블릿클래스들의변경을모니터링한다. 자세한내용은 제3장웹컨텍스트 를참고한다. 세션서비스모니터링클라이언트세션의기한만료여부를체크하고만료된세션을제거한다. 세션서비스모니터링에대한자세한내용은 JEUS 세션관리안내서 의 제1장세션트래킹 (Session Tracking) 을참고한다. 기본오류페이지설정웹엔진은해당컨텍스트가준비되지않은상태에서보여줄오류페이지를설정할수있다. 설정에대한자세한내용은 1.6.3. 기본오류페이지설정 을참고한다. 오류발생의경우 Stack Trace 첨부설정웹엔진은오류가발생했을경우오류가발생한지점의 Stack Trace를기본오류페이지에첨부할지여부를설정할수있다. 설정에대한자세한내용은 1.6.4. 오류발생의경우 Stack Trace 첨부설정 을참고한다. 인코딩설정웹엔진은등록된모든컨텍스트에의해사용될수있는인코딩설정을가지고있다. 설정에대한자세한내용은 1.6.5. 인코딩설정 을참고한다. JSP 엔진설정모든웹엔진은 JSP 엔진을포함하고있다고볼수있다. JSP 엔진은 JSP 자원을클라이언트가요청했을때 JSP 페이지들을 Java 파일로변환후이 Java 파일을컴파일하여서블릿바이트코드로생성하는작업을한다. 실행결과로하나의 JSP에대해 Java 파일과클래스파일이생성된다. 설정에대한자세한내용은 4.4. JSP 엔진설정 을참고한다. 제 1 장웹엔진 3

응답헤더설정웹엔진은사용자임의의 HTTP Response Header의이름과값의짝을설정할수있다. 사용자임의의응답헤더를설정할경우해당웹엔진에서나가는모든응답에는정의된헤더가항상포함된다. 설정에대한자세한내용은 1.6.7. 응답헤더설정 을참고한다. 세션관리웹엔진의세션관리에대한여러가지사항을설정한다. 세션클러스터링의참여여부, 세션객체의공유여부, 세션쿠키 (Session Cookie) 설정, 타임아웃등웹엔진의세션과관련된모든설정을할수있다. 설정에대한자세한내용은 1.6.9. 세션설정 과 JEUS 세션관리안내서 의 제1장세션트래킹 (Session Tracking) 을참고한다. Event Logging 웹엔진에서남기는로그는서버로그와액세스로그이다. 그리고웹애플리케이션에서 ServletContext API의 log 메소드로남기는유저로그가있다. 구분서버로그액세스로그유저로그 설명웹엔진의동작에관련된로그이다. 웹엔진에요청및처리결과에대한로그이다. javax.servlet.servletcontext.log(string msg) 또는 javax.servlet.servletcon text.log(string msg, Throwable t) API를사용하여웹애플리케이션내에서생성되는메시지를기록하는로그이다. JEUS 로그의기본위치는 1.5. 디렉터리구조 를참고하고, 로그설정에대한자세한내용은 1.6.10. 로그설정 을참고한다. Graceful Shutdown 관리자가 JEUS 서버를 Shutdown할때이미진행중이던서비스완료를보장하는기능이다. 실제로관리자가 Shutdown 명령을내리면다음과같은순서로동작한다. 1. 더이상새로운서비스요청을받지않는다. 2. 그시점에이미진행중이던요청들의완료를보장한뒤다른 Shutdown 작업을진행한다. 진행중이던서비스가너무오래걸릴경우무한정기다릴수없으므로서버에 Shutdown 명령을내릴때타임아웃옵션을설정할수있다. Graceful Shutdown에대한자세한내용은 JEUS Server 안내서 의 3.1.3. Managed Server 종료 를참고한다. 참고 JEUS 6까지제공하던 WEBMain.xml의 shutdown-timeout 설정은더이상제공하지않는다. 대신콘솔툴 (jeusadmin) 에서 shutdown timeout 옵션을설정하면동일한기능을수행한다. 웹공격대응 DoS(Denial of Service) 공격과같은웹공격으로인한 JEUS 서버의부담을덜기위한설정을제공한다. 4 JEUS Web Engine 안내서

웹공격을방지하는설정으로 POST 요청의크기제한설정, GET/POST 요청에포함된파라미터들의개수제한, 하나의요청에표함된헤더의개수제한, 하나의요청내에포함된헤더하나의크기제한, 그리고 GET 요청의 query string의크기제한을설정할수있다. 이들에대한자세한설정은 1.6.13. 웹공격대응설정 을참고한다. 1.4. 관리도구 본절에서는웹엔진의제어및모니터링기능을제공하는도구에대해설명한다. 1.4.1. 도구종류 JEUS 웹엔진을운영하기위한도구들은다음과같다. WebAdmin 웹브라우저로웹엔진을관리할수있는운영도구이다. JEUS WebAdmin( 이하 WebAdmin) 의사용법은 "JEUS WebAdmin 안내서 " 를참고한다. 콘솔툴 (jeusadmin) OS 콘솔에서웹엔진을제어할수있는운영도구이다. 기본적인제어기능과모니터링기능을제공한다. 콘솔툴의사용법은 JEUS Server 안내서 의 제3장 JEUS 서버제어및모니터링 과 JEUS Reference Book 의 4.2.8. 웹엔진관련명령어 를참고한다. 1.4.2. 제어와모니터링 운영도구를이용하여웹엔진의제어및모니터링이가능하다. 웹엔진제어 웹엔진을제어한다는것은웹엔진의시작과종료를제어한다는의미와같다. 이 2가지작업은 WebAdmin 과콘솔툴을사용하여가능하다. WebAdmin 사용콘솔툴과마찬가지로자세한내용은 JEUS Server 안내서 의 제3장 JEUS 서버제어및모니터링 의서버제어설명을참고한다. 콘솔툴사용웹엔진은 JEUS 서버에포함되며, 서버와별도로제어할수있는방법은없다. 자세한내용은 JEUS Server 안내서 의 제3장 JEUS 서버제어및모니터링 을참고한다. 제 1 장웹엔진 5

웹엔진모니터링 WebAdmin과콘솔툴을사용해서웹엔진을모니터링할수있다. 콘솔툴사용콘솔툴에서는웹엔진에대한기초정보를조회할수있는기능을제공한다. 자세한내용은 "JEUS Server 안내서 " 와 JEUS Reference Book 의 4.2.8. 웹엔진관련명령어 를참고한다. WebAdmin 사용 WebAdmin을통해웹엔진을모니터링할수있다. WebAdmin의엔진통계부분을이용한다. 1. WebAdmin 왼쪽메뉴에서 [Monitoring] 을선택하면아래로모니터링가능한모듈이나열된다. 여기서 [Web] 을선택하면웹엔진의통계정보를조회하거나초기화할수있다. [ 그림 1.2] 웹엔진모니터링 - 메뉴이동 6 JEUS Web Engine 안내서

2. Webinfo 화면의 'Server' 에서모니터링을원하는서버를선택하면선택된서버의웹엔진통계정보가다음과같이조회된다. 통계정보의오른쪽상단의 [CLEAR] 버튼을클릭하면클릭한시점을기준으로 Request information of contexts 통계정보가초기화된다. [ 그림 1.3] server1 웹엔진모니터링 - 정보조회 Webinfo 화면에서조회되는각통계정보에대한설명은다음과같다. 통계정보 Standard session informa tion Distributed session infor mation 설명선택된서버의웹엔진에동작중인세션매니저의통계정보를표시한다. 기본적으로세션의개수를표시한다. 선택된서버웹엔진에동작중인세션매니저의통계정보를표시한다. 해당정보는클러스터환경에서만표시되며, 매니저가가진세션과백업서버의 제 1 장웹엔진 7

통계정보 설명 정보를표시한다. 클러스터환경 / 설정에대한자세한내용은 JEUS 세션관 리안내서 의 2.2. 기본개념 를참고한다. Thread information Request information of contexts Memory information 선택된서버의웹엔진에설정된각각의리스너및커넥터의 Thread Pool 내의 Thread들의상태통계정보를표시한다. 선택된서버의웹엔진에배치된웹애플리케이션별로누적처리요청수, 누적요청처리시간, 평균요청처리시간을표시한다. [CLEAR] 버튼을클릭하면정보가초기화된다. 선택된서버의총 VM 메모리와사용가능한 VM 메모리를표시한다. 1.5. 디렉터리구조 JEUS 디렉터리구조에서의웹엔진구조는다음과같다. [ 그림 1.4] JEUS 디렉터리구조에서의웹엔진 JEUS_HOME JEUS 설치홈디렉터리이다. 8 JEUS Web Engine 안내서

domains/domain1/config/ JEUS_HOME의 domains 디렉터리하위에는각도메인이름을기준으로디렉터리가존재한다. 이중에서웹엔진의설정과관련되는내용이 config 디렉터리아래에위치한다. domain1은예시로사용한도메인이름이다. domain.xml은통합된설정파일이다. 해당파일에도메인에속한모든서버의설정이있으며, 각서버별로웹엔진을설정할수있다. 참고 1. domain.xml에관한자세한내용은 "JEUS Server 안내서 " 를참고한다. 2. JEUS 7부터는더이상 WEBMain.xml을사용하지않는다. 3. JEUS 7부터는하나의서버 JVM에는하나의웹엔진만존재하므로엔진별설정디렉터리가필요없다. servlet/ 도메인에속한모든서버들이각웹애플리케이션을 deploy할때기본적으로참조하는 XML 설정파일이위치한다. 파일 web.xml webcommon.xml 설명 Servlet 3.0부터는 web.xml이기본적으로없어도된다. 그러나 JSP Parser인 Tomcat Jasper에서는이파일을기반으로웹애플리케이션의버전을확인하므로되도록그대로유지하기바란다. web.xml 파일을가지고있지않은웹애플리케이션에서이파일을참고한다. 모든웹애플리케이션들에적용되는공통설정파일이다. 이파일의형식은 web.xml 형식과동일하다. 참고이디렉터리에있는 web.xml과 webcommon.xml은도메인에속한서버들이부팅될때도메인관리서버로부터받아오게되므로도메인의서버들은같은파일을유지하게된다. servlet/server1/ servlet 설정디렉터리아래에특정서버이름으로디렉터리를생성하고그아래에 webcommon.xml, web.xml을위치시키면특정서버에대해서만적용할수있다. 이디렉터리의설정이상위디렉터리에있는설정에우선한다. 참고 특정서버이름의디렉터리에있는 web.xml 과 webcommon.xml 은 JEUS 가자동으로관리하지않는 다. 그러므로이설정파일들은서버관리자가수동으로관리해야한다. 제 1 장웹엔진 9

domains/domain1/servers/server1/logs 도메인에속한각서버가동작할때생성되는파일들은모두 servers 아래에각서버별이름으로생성된디렉터리아래에존재한다. 이에관한자세한내용은 JEUS Server 안내서 의 제8장 Logging 을참고한다. 로그파일은기본적으로 logs 디렉터리아래에있다. 웹엔진에서생성한로그는 JeusServer.log에저장된다. 단, 로그로테이션기능에의해파일이름은변경될수있지만항상 JeusServer로시작한다. servlet/ 웹애플리케이션액세스로그인 access.log를저장한다. 만약가상호스트별로액세스로그를설정했을경우에는기본적으로이디렉터리아래에가상호스트이름으로디렉터리를생성하고, 해당가상호스트에 deploy된웹애플리케이션들의액세스로그를저장한다. 자세한내용은 제5장가상호스트 를참고한다. 또한, 이디렉터리에는웹애플리케이션에서 ServletContext API의 log 메소드를통해서남기는유저로그인 user.log 또는 user_appname.log 파일을저장한다. 유저로그는설정에따라서 user.log 파일에남을수도있고, 웹애플리케이션별도의파일인 user_appname.log에남을수도있다. 1.6. 환경설정 본절에서는웹엔진와관련된환경설정파일과웹엔진설정에대해설명한다. 웹엔진에대한설정은 WebAdmin을사용해서진행할것을권장한다. WebAdmin을사용한설정은다음과같은몇가지설정관련공통적인사항에대한지식이필요하다. [LOCK & EDIT] 버튼각항목을설정및수정하려면화면왼쪽의 [LOCK & EDIT] 버튼을클릭하여설정변경모드로전환해야한다. 설정변경모드로전환하지않으면설정및수정이불가능하다. [ 확인 ] 및 [ 재설정 ] 버튼설정변경모드로전환하여설정을변경한후에는 [ 확인 ] 버튼을클릭하여수정및설정내용을저장한다. [ 재설정 ] 버튼을클릭하면수정및설정하기전의설정내용으로되돌린다. [Activate Changes] 버튼수정및설정내용을선택된서버로반영하려면반드시 [Activate Changes] 버튼을클릭해야한다. 단, 동적으로반영되지않는설정인경우에는해당설정이 pending되었다는메세지와함께 " 변경사항을적용하기위해서 Server를재시작해야합니다 " 라는메시지가출력된다. 이경우서버를재시작해야 pending된설정이실제서버에적용된다. 10 JEUS Web Engine 안내서

[ 그림 1.5] 설정적용 - Activate Changes 고급선택사항웹엔진의각설정에는기본설정과고급선택사항설정이존재한다. 기본설정기본적인설정항목으로각항목에대한설명이기본으로표시된다. 고급선택사항일반설정외에고급설정을위한항목들로구성되어별도의영역으로구분되고, 각설정항목에대한설명이기본으로표시되지않는다. 고급선택사항영역상단에 ' 모두열기 ' 를클릭하면각항목에대한설명이화면에표시된다. 제 1 장웹엔진 11

[ 그림 1.6] 고급선택사항 참고 WebAdmin 의사용방법에대한자세한내용은 "JEUS WebAdmin 안내서 " 를참고한다. 12 JEUS Web Engine 안내서

1.6.1. XML 설정파일 다음은웹엔진과관련된 XML 설정파일들에대한설명이다. domain.xml (jeus-domain.xsd) 위치 목적 상세정보 JEUS_HOME/domains/<domain-name>/config JEUS 서버별웹엔진설정 "JEUS Server 안내서 " jeus-web-dd.xml (jeus-web-dd.xsd) 위치 목적 상세정보 <packaged web application>/web-inf/ JEUS 웹모듈 Deployment Descriptor( 이하 DD) 본안내서 web.xml (web-app_3_0.xsd) 위치 목적 상세정보 <packaged web application>/web-inf/ Java EE 표준웹모듈 DD Servlet 3.0 표준 web.xml (web-app_3_0.xsd) 위치 목적 상세정보 JEUS_HOME/domains/<domain-name>/config/servlet web.xml 을개별적으로가지고있지않은웹모듈의 web.xml Servlet 3.0 표준 webcommon.xml (web-app_3_0.xsd) 위치 목적 상세정보 JEUS_HOME/domains/<domain-name>/config/servlet 웹엔진의모든웹모듈에적용되는공통설정파일 Servlet 3.0 표준 XML 스키마파일들은 JEUS_HOME/lib/schemas/jeus/ 디렉터리에위치한다. 위파일들의내용은반드시표준즉, JEUS 에서정의된 XML 헤더로시작되어야한다. 또한 Root Element 는 JEUS XML 스키마의 namespace 를기존 name-space 로지정해야한다. 제 1 장웹엔진 13

각파일에사용되는헤더는다음과같다. web.xml의 XML 헤더는서블릿표준에포함되어있다. domain.xml의 XML 헤더 [ 예 1.1] XML 헤더 : <<domain.xml>> <?xml version="1.0" encoding="utf-8"?> <domain xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0"> jeus-web-dd.xml의 XML 헤더 [ 예 1.2] XML 헤더 : <<jeus-web-dd.xml>> <?xml version="1.0" encoding="utf-8"?> <jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus"> web.xml의 XML 헤더 [ 예 1.3] XML 헤더 : <<web.xml >> <?xml version="1.0" encoding="utf-8"?> <web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"> 참고본안내서에서사용되는모든태그순서는 XML 스키마의설정순서대로작성되어있다. 실제사용할때는순서를제대로지키기가쉽지않으므로, JEUS에서는태그순서를자동으로정렬해주는기능을제공한다. 그러므로 XML 설정파일을작성할때, 순서를정확하게지키지않아도무방하다. 태그순서는 "JEUS XML Reference" 를참고한다. 주의 위파일들의예제가본안내서에서사용될때에는표준헤더가편의상생략되어사용되고있다. 실제 XML 설정파일에는이헤더들이포함되어있다는것에주의한다. 14 JEUS Web Engine 안내서

1.6.2. 모니터링설정 웹엔진은내부 Thread와클래스변경사항, 세션의변경사항을모니터링할수있고, 이들의모니터링주기를변경할수있다. WebAdmin을사용해서모니터링주기를설정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. [ 그림 1.7] 모니터링 - 설정메뉴이동 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 제 1 장웹엔진 15

3. Web Engine 설정화면의고급선택사항영역에서다음과같이 Monitoring 의각항목을설정하고 [ 확 인 ] 버튼을클릭한다. [ 그림 1.8] 모니터링 - 설정 Monitoring 의각설정항목에대한설명은다음과같다. 항목 Check Thread Pool 설명 요청처리스레드들의상태를점검하기위한시간간격을설정한다. ( 기본값 : 300000(5 분 )) Check Class Reload 웹컨텍스트를자동으로리로드하기위해클래스변경여부를체크하는주기 를설정한다. ( 기본값 : 300000(5 분 )) 이설정은 jeus-web-dd.xml 에 <auto-reload><enable-reload> 기능을설정해야 의미를갖는다. <check-on-demand> 를 true 로설정한웹컨텍스트의경우에는 점검하지않는다. Check Session 세션의타임아웃상태점검주기를설정한다. 세션의타임아웃은웹엔진의세 션설정이나 web.xml 에설정된다. ( 기본값 : 300000(5 분 )) 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 16 JEUS Web Engine 안내서

5. 모니터링설정내용이반영되면다음과같이화면에반영결과가나타난다. 모니터링설정은동적반영 이되지않으므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.9] 모니터링 - 설정적용결과 1.6.3. 기본오류페이지설정 웹요쳥은웹컨텍스트가존재하는경우에오류가발생하면해당웹컨텍스트에서오류를처리한다. 그러나웹컨텍스트가존재하는않는경우에는웹엔진이내부적으로에러페이지를보내주는방법으로오류를처리해야한다. 이경우오류페이지가사용자가원하는형식이아닐수있으므로이런사용자의요구사항을처리할수있는오류페이지의절대경로를지정할수있는설정을제공한다. 단, 이경우에는 html 또는 htm 파일만설정이가능하다. 여기에설정된값은 HTTP 응답내용으로만사용될뿐이며 forward 개념이아니다. WebAdmin을사용해서기본오류페이지를설정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 제 1 장웹엔진 17

3. Web Engine 화면에서기본오류페이지와관련된 'Default Error Page' 항목에다음과같이오류페이 지의절대경로를설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 1.10] 기본오류페이지 - 설정 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 18 JEUS Web Engine 안내서

5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 'Default Error Page' 는동적설정항 목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.11] 기본오류페이지 - 설정적용결과 1.6.4. 오류발생의경우 Stack Trace 첨부설정 웹요청처리중웹엔진에문제가발생했을때오류의상세내역을 JEUS가기본적으로제공하는오류페이지에표시할것인지에대한설정이다. 이메시지는개발할때는유용하지만, 운영할때는제거하는것이바람직하다. 이에대한설정은 WebAdmin을사용하여웹엔진에적용하거나각애플리케이션별 jeus-web-dd.xml에서설정가능하다. jeus-web-dd.xml의설정은 3.3.1. jeus-web-dd.xml 설정 을참고한다. WebAdmin을사용하여오류가발생한경우의 Stacktrack 첨부여부를설정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 제 1 장웹엔진 19

2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Web Engine 화면에서 'Attach Stacktrace on Error' 항목을 Boolean 값으로설정하고 [ 확인 ] 버튼을클릭한다. 기본값은 false이고, 항목을체크하면기본오류페이지관련설정인 'Default Error Page' 항목이설정되지않은경우에웹엔진의기본오류페이지에첨부되어사용자에게전달된다. 기본오류페이지관련설정에대한자세한내용은 1.6.3. 기본오류페이지설정 을참고한다. [ 그림 1.12] 오류발생시 Stack Trace 첨부 - 설정 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 'Attach Stacktrace on Error' 는동 적설정항목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. 20 JEUS Web Engine 안내서

[ 그림 1.13] 오류발생시 Stack Trace 첨부 - 설정적용결과 1.6.5. 인코딩설정 웹엔진은엔진내의모든컨텍스트에의해사용될수있는 3가지인코딩설정을가지고있다. Request Url Encoding HTTP 요청 URL을위한인코딩이다. Request Url Encoding은웹브라우저로부터받은 HTTP 요청의 Request Line에적용된다. Request Url Encoding이설정되지않은경우에는 Request Encoding이적용된다. 일반적으로 Request Url Encoding 을지정해야하는경우는 HTTP Request Line의인코딩이 HTTP 바디와다른특별한경우이다. Request Url Encoding은다음의우선순위에따라적용된다. 1. domain.xml에정의된 "forced" 인코딩 2. HTTP 헤더의 "Accept-Language" 필드값에해당하는인코딩 3. domain.xml에정의된 "default" 인코딩 제 1 장웹엔진 21

4. 위의어떤것도적용되지않으면기본적으로 "ISO-8859-1" 로설정기본적으로우선순위에따라적용되지만, 사용자가 Request 객체에 setcharacterencoding() 으로설정한경우에는 query string 및쿠키에대해서는사용자가설정한인코딩이최우선적으로적용된다. 따라서관리자는 domain.xml에 "default" 와 "forced" 요청인코딩을정의할수있다. "default" 와 "forced" 를동시에설정하는것은의미가없으므로둘중하나만설정한다. Request Encoding HTTP Request Header의 query string, 쿠키및 postdata에사용되는인코딩이다. 이인코딩은 jeus-web-dd.xml에서도설정이가능하며, jeus-web-dd.xml의설정이우선적으로적용된다. Request Encoding은다음의우선순위에따라적용된다. 1. 애플리케이션 (Servlet/JSP) 에서의설정 (request.setcharacterencoding() 으로설정한인코딩 ) 2. domain.xml에정의된 "forced" 인코딩 3. HTTP 요청의 Content-Type의 charset에의한인코딩 4. HTTP 헤더의 "Accept-Language" 필드값에해당하는인코딩 5. domain.xml에정의된 "default" 인코딩 6. 위의어떤것도적용되지않으면기본적으로 "ISO-8859-1" 로설정기본적으로우선순위에따라적용되지만, jeus-web-dd.xml에설정한경우에는 jeus-web-dd.xml의설정이우선적으로적용된다. HTTP Request Line의 query string은다음과같은우선순위로인코딩이적용된다. 1. request.setcharacterencoding() 으로지정한인코딩 2. Request Url Encoding : 애플리케이션에서설정되지않은경우 3. Request Encoding : Request Url Encoding이설정되지않은경우 Response Encoding 웹컨테이너로부터받은전체응답 HTTP 메시지에적용되는인코딩이다. Response Encoding은 PrintWriter.println() 을 Byte 배열로변환할때 HTTP 헤더의 "Content- Type:text/html;charset=XXX" 부분의 "XXX" 값을설정하고웹컨테이너의응답에어떤인코딩을사용할지결정한다. 이인코딩역시 jeus-web-dd.xml에서도설정이가능하다. Response Encoding은다음의우선순위목록에따라적용된다. 1. domain.xml에정의된 "forced" 인코딩 2. 서블릿에서의설정 (Servlet에서는 response.setcontenttype ("text/html;charset=xxx"), JSP에서는 <%@ page contenttype="text/html;charset=xxx"%> 로프로그래머가설정한 XXX 값의인코딩 ) 3. domain.xml에정의된 "default" 인코딩 22 JEUS Web Engine 안내서

4. 위의어떤것도적용되지않으면기본적으로 "ISO-8859-1" 로설정된다. 기본적으로우선순위에따라적용되지만 jeus-web-dd.xml에설정한경우에는 jeus-web-dd.xml의설정이우선적으로적용된다. 관리자는 domain.xml에 "default" 와 "forced" Response Encoding을정의할수있다. WebAdmin 사용 WebAdmin을사용하여인코딩을설정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 고급선택사항의 Encoding 영역에서 'Request Url Encoding', 'Request Encoding', 'Response En coding' 항목을설정하고 [ 확인 ] 버튼을클릭한다. 'Request Url Encoding' 을제외하고 jeus-web-dd.xml에서도설정이가능하다. [ 그림 1.14] 웹엔진인코딩 - 설정 제 1 장웹엔진 23

각항목별로 'Default' / 'Forced' 중하나를선택하여활성화한후설정할인코딩명을입력한다. 설정값 Default Forced 설명 어떤인코딩도없을경우에기본값으로사용한다. 해당인코딩을모든경우에항상강제적으로사용한다. 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 'Attach Stacktrace on Error' 는동적설정항목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.15] 웹엔진인코딩 - 설정적용결과 참고 JEUS 6까지는위의 <default> 와 <forced> 를동시에설정하는것이가능했다. 그러나두값이모두설정되면 <forced> 가적용될것이므로동시에설정되는것은의미가없기때문에 JEUS 7에서는이부분을서로배타적으로설정하도록변경했다. 1.6.6. JSP 엔진설정 웹엔진은 JSP 엔진을포함하고있다. 따라서 JSP 에관한설정은웹엔진또는각웹애플리케이션별로 해야한다. 이에대한자세한내용은 제 4 장 JSP 엔진 을참고한다. 24 JEUS Web Engine 안내서

1.6.7. 응답헤더설정 사용자임의의 HTTP Response Header를이름과값의짝으로정의할수있다. WebAdmin을사용하여응답에기본적으로포함될사용자정의헤더를설정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 고급선택사항의 Response Header 영역의항목을설정하고 [ 확인 ] 버튼을클릭한다. 다음은응답에 2개의사용자정의헤더를설정한예제이다. 1개이상의응답헤더를설정할경우에는각헤더들의헤더명과헤더값을등호 (=) 로연결하고, 라인별로구분한다. [ 그림 1.16] 웹엔진응답헤더 - 설정 설정항목에대한설명은다음과같다. 항목 Custom Header 설명 HTTP 응답메시지에포함하기위한커스텀필드를정의한다. 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 제 1 장웹엔진 25

5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 'Custom Header' 는동적설정항목 이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.17] 웹엔진응답헤더 - 설정적용 1.6.8. 쿠키정책설정 HTTP Request Header의쿠키를읽거나애플리케이션이생성한새로운쿠키를 HTTP 응답으로보낼때적용하는정책을설정할수있다. 쿠키정책설정은웹엔진에대하여 WebAdmin을통하여설정할수있고, 또한각애플리케이션별로 jeus-web-dd.xml 에서설정가능하다. WebAdmin을사용하여쿠키정책을설정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 26 JEUS Web Engine 안내서

3. 고급선택사항의 Cookie Policy 영역의항목을설정하고 [ 확인 ] 버튼을클릭한다. 다음은쿠키정책으로 UTF-8 인코딩을사용하여쿠키인코딩수행을설정한예제이다. [ 그림 1.18] 웹엔진쿠키정책 - 설정 항목 Apply Url Encoding Rule Charset Encoding 설명 URL Encoding Rule의적용여부를설정한다. URL Encoding Rule을적용할때사용하는 Charset Encoding이다. 설정하지않을경우 Request Encoding의값을따른다. 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 쿠키정책은동적설정항목이아니 므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. 제 1 장웹엔진 27

[ 그림 1.19] 웹엔진쿠키정책 - 설정적용결과 1.6.9. 세션설정 웹엔진의세션관리를위한세션객체의공유여부, 세션쿠키설정, 타임아웃등웹엔진의세션과관련된모든사항을설정한다. 세션설정은다음과같이구분된다. 웹엔진레벨 : WebAdmin을사용해서세션을설정한다. 세션설정에대한자세한내용은 JEUS 세션관리안내서 의 1.6.1. 세션설정 을참고한다. 컨텍스트레벨 : jeus-web-dd.xml의 <jeus-web-dd> 하위에설정한다. 웹엔진레벨에서세션이설정되어있다면, 컨텍스트레벨에서세션을설정하지않아도공통적으로웹엔진의세션설정이적용된다. 웹엔진레벨, 컨텍스트레벨의설정이중복되었을경우하위레벨의세부적인설정에가장높은우선순위를부여한다. 즉, 모두설정이되어있다면컨텍스트레벨 > 웹엔진레벨순으로설정값이적용된다. 만약하위레벨에서특정설정을하지않았다면상위레벨의설정값을적용하고모든레벨에서설정하지않은값은엔진내부적인기본값으로동작한다. 참고 클러스터링된환경에서의세션관련사항에대한자세한내용은 JEUS 세션관리안내서 의 제 1 장세션트래킹 (Session Tracking) 을참고한다. 28 JEUS Web Engine 안내서

1.6.10. 로그설정 본절에서는각로그들의설정방법에대해설명한다. 서버로그설정 액세스로그기본설정 가상호스트별액세스로그설정 액세스로그의포맷설정 액세스로그의필터설정 유저로그설정 서버로그설정 서버로그설정에대한자세한내용은 JEUS Server 안내서 의 제 8 장 Logging 을참고한다. 액세스로그기본설정 웹엔진액세스로그는 WebAdmin 을통해설정한다. 특별히설정하지않아도기본적으로액세스로그를 파일로남기도록설정되어있다. 참고 JEUS v6.0 Fix #8부터는액세스로그도기본적으로로그로테이션을적용한다. 로그로테이션이란 JEUS에서제공하는기능으로 JEUS가시작될때또는 JEUS 운영중에설정한시간이되거나파일사이즈를넘으면자동으로이전에 Logging하던파일의이름은바꾸고새로출력할로그들은원래의로그파일에계속 Logging할수있는기능이다. WebAdmin을사용한액세스로그기본설정방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Access Log] 메뉴를선택한다. 제 1 장웹엔진 29

[ 그림 1.20] 웹엔진액세스로그 - 설정메뉴이동 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 설정항목중필요한항목을설정한다. 기본설정을사용할경우에는특별히수정할필요가없다. 주로액세스로그의포맷을변경할경우나특정확장자의접근을액세스로그에포함시키지않을경우에필요한설정을할수있다. 기본적으로존재하는파일핸들러이외에다른핸들러를추가하려면설정화면의아래의 Handlers 영역에서추가한다. 핸들러에대한자세한내용은 JEUS Server 안내서 의 제8 장 Logging 을참고한다. 30 JEUS Web Engine 안내서

다음은액세스로그의형식을기본형식에서사용자가원하는형식으로수정하는예제이다. [ 그림 1.21] 웹엔진액세스로그 - 설정 고급선택사항의각항목에대한설명은다음과같다. 항목 Filter Class Formatter Class 설명 Logger 에지정할필터클래스의이름을설정한다. 해당 Logger 의핸들러에지정할 Formatter 클래스의이름을설정한다. 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 제 1 장웹엔진 31

5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 액세스로그설정중일부항목은동 적설정항목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.22] 웹엔진액세스로그 - 설정적용결과 가상호스트별액세스로그설정 가상호스트별로액세스로그를남기려면각가상호스트설정에액세스로그를설정해야한다. 이에대한 자세한내용은 5.4. 가상호스트설정 을참고한다. 32 JEUS Web Engine 안내서

액세스로그의포맷설정 WebAdmin을사용해서액세스로그의포맷을설정할수있다. WebAdmin의 [Servers] 메뉴를클릭하여나타나는서버목록에서서버를선택하고, [Engine] > [Web Engine] > [Access Log] 메뉴로이동하여 Access Log 화면의 'Format' 항목을설정할수있다. ([ 그림 1.21] 참고 ) 포맷에는기본적으로 '%' 기호를이용해서데이터를나타내며, 임의의문자열도가능하다. JEUS 7부터는 Common Log Format( 이하 CLF) 을따른다. 참고 1. CLF에대한자세한사항은 http://httpd.apache.org/docs/2.0/logs.html을참고한다. 2. 콘솔툴을이용한포맷설정변경은 JEUS Reference Book 의 4.2.8.19. modify-web-engineconfiguration 을참고한다. 웹엔진은다음과같은포맷 Alias를제공한다. default JEUS에서기본적으로제공하는포맷이다. CLF에서가장많이사용하는 common 포맷에처리시간 (%D) 를추가한포맷이다. %h %l %u %t \"%r\" %>s %b %D common CLF 에서가장많이사용하는포맷으로아래의포맷을 Alias 한다. %h %l %u %t \"%r\" %>s %b combined HTTP 헤더에서 Referer 와 User-agent 를찍어주는포맷으로아래의포맷을 Alias 한다. %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" debug default 포맷에 %S( 세션 ID) 와 %I( 요청처리스레드이름 ) 을추가한포맷이다. %h %l %u %t \"%r\" %>s %b %D %S \"%I\" 6deprecated JEUS 6 까지제공하던형식이다. JEUS 7 부터는별도의 Log Analyzer 를제공하지않으므로이형식을 사용하는것을권장하지않는다. 위의포맷 Alias 를이용해서다음과같은형식으로포맷을지정할수도있다. default %S 이경우에웹엔진에서 common 을치환해서다음과같이등록한다. 제 1 장웹엔진 33

%h %l %u %t \"%r\" %>s %b %D %S 이포맷설정은서비스도중에도변경이가능하며, 그변경사항이적용된다. 따라서현재제공하는서비스에문제가있는경우 debug 포맷을설정해서세션 ID, 응답처리 Thread 이름을액세스로그에남길수있다. 액세스로그의프로그래밍방식필터설정 액세스로그의필터기능은액세스로그의양이지나치게많을경우특정형식또는조건을만족하는내용만로그로기록하고싶을경우를위해제공되는기능이다. 참고 1. <exclude-ext> 를통해서특정확장자로끝나는요청에대해서필터링을지원하고있다. 2. JEUS 7 부터는 jeus.servlet.util 패키지에서 jeus.servlet.logger 패키지로변경되었다. JEUS에서는 jeus.servlet.logger.accessloggerfilter 인터페이스및 jeus.servlet.logger.abstractaccesslog gerfilter 추상클래스를제공하고있다. [ 예 1.4] jeus.servlet.logger.accessloggerfilter 인터페이스의상세내용 package jeus.servlet.logger; import java.util.logging.filter; import java.util.logging.logrecord; /** * Access Logger의내용을필터링하기위해필요한정보들을제공하는인터페이스. * {@link Filter} 를상속한필터인터페이스로서부수적으로제공되는인터페이스를통해 * {@link Filter#isLoggable(java.util.logging.LogRecord)} 안에서다양하게필터링정책을정하도록가이드한다. */ public interface AccessLoggerFilter extends Filter { /** * 서버에접속한 remote client의 address 정보를반환한다. * * @param record a LogRecord * @return remote client의 address. 만약올바른값을얻지못할경우 null을반환한다. */ public String getremoteaddr( LogRecord record ); /** * 요청의메소드를반환한다. ex) GET, POST, PUT, etc... * * @param record a LogRecord * @return request method. 만약올바른값을얻지못할경우 null을반환한다. 34 JEUS Web Engine 안내서

*/ public String getmethod( LogRecord record ); /** * 요청의 uri를반환한다. * * @param record a LogRecord * @return request uri. 만약올바른값을얻지못할경우 null을반환한다. */ public String getrequesturi( LogRecord record ); /** * 응답의 status값을반환한다. ex) 200, 404 * * @param record a LogRecord * @return status. */ public int getstatus( LogRecord record ); } /** * 요청에따른처리시간을 ms단위로반환한다. * @param record a LogRecord * @return processing time. 만약올바른값을얻지못할경우 -1을반환한다. */ public long getprocessingtimemillis( LogRecord record ); 사용자가액세스로그의특정패턴에대해필터링하는경우위의 AccessLoggerFilter 인터페이스및 Ab stractaccessloggerfilter 추상클래스를이용하여쉽게필터를구현하고적용할수있다. 사용자의필터클래스는 jeus.servlet.logger.abstractaccessloggerfilter를상속하고, java.util.logging.filter 의 isloggable() 메소드를구현해야한다. isloggable() 메소드를구현할때, 위의 jeus.servlet.logger.ac cessloggerfilter의 API 중에서사용자가필요한정보를적절히선택하여이용및구현한다. 다음은요청확장자가 '.gif' 인경우액세스로그로기록하지않는필터클래스를정의한예이다. [ 예 1.5] 필터클래스정의예제 package sample; import jeus.servlet.logger.abstractaccessloggerfilter; import java.util.logging.*; public class SimpleAccessLoggerFilter extends AbstractAccessLoggerFilter { public boolean isloggable(logrecord record) { String requesturi = getrequesturi(record); return requesturi!= null &&!requesturi.endswith(".gif"); 제 1 장웹엔진 35

} } sample.simpleaccessloggerfilter는사용자가정의한클래스이며 jeus.servlet.logger.abstractaccess LoggerFilter를 extends한다. java.util.logging.filter#isloggable() 메소드를구현하였으며, 클라이언트의요청 URI를얻기위해 jeus.servlet.util.accessloggerfilter#getrequesturi() API를이용한다. 클래스정의가완료되면해당클래스를컴파일한다. 그다음 JAR 파일형태로 JEUS_HOME/domains/DO MAIN_HOME/lib/application 디렉터리에포함시키고, 웹엔진액세스로그설정에해당필터를설정한다. 액세스로그설정방법은 " 액세스로그기본설정 " 을참고한다. 유저로그설정 아무런설정을하지않을경우에는서버로그파일 (JeusServer.log) 에로그가남는다. 만약별도의로그파일을남기고싶은경우에는유저로그를설정한다. 유저로그의기본위치및파일은 1.5. 디렉터리구조 를참고한다. 유저로그는서버로그와마찬가지로 JEUS 서버레벨에서등록할수있고, 웹애플리케이션의 jeus-webdd.xml에등록할수도있다. 또한각웹애플리케이션별로남길수도있고, 특정로그파일에모아서남길수도있다. WebAdmin을사용한유저로그설정방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Basic] > [User Logging] 메뉴를선택한다. 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 36 JEUS Web Engine 안내서

3. webapp이라는이름의웹애플리케이션만의로그를생성하기위해 'Name' 항목을다음과같이설정한다. webapp 이름없이 'jeus.systemuser' 를입력하면모든웹애플리케이션에유저로그가적용된다. 고급선택사항의각항목에대한설명은 " 액세스로그기본설정 " 을참고한다. 그외에 'Level' 이나고급선택사항은필요한경우설정한다. [ 그림 1.23] 유저로그 - 설정 제 1 장웹엔진 37

4. 유저로그명을설정한다음 [ 확인 ] 버튼을클릭하면, Handlers 영역아래에핸들러를추가할수있는버튼이추가된다. [FILE HANDLER], [SMTP HANDLER], [SOCKET HANDLER], [USER HANDLER] 중추가할핸들러의종류에맞는버튼을클릭해서유저로그의핸들러를추가한다. 각핸들러의설정방법은 JEUS Server 안내서 의 제8장 Logging 을참고한다. 본예제에서는파일핸들러추가를위해 [FILE HANDLER] 버튼을클릭한다. [ 그림 1.24] 유저로그 - 핸들러추가 38 JEUS Web Engine 안내서

5. 유저로그핸들러추가를위해 File Handler 화면에서각항목을설정한후 [ 확인 ] 버튼을클릭해서추 가를완료한다. [ 그림 1.25] 유저로그 - 핸들러설정 제 1 장웹엔진 39

6. 핸들러추가가완료되면다음과같이추가된핸들러가표시된다. [ 그림 1.26] 유저로그 - 핸들러추가확인 7. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 40 JEUS Web Engine 안내서

8. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 유저로그설정중일부항목은동적 설정항목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.27] 유저로그 - 핸들러추가적용결과 제 1 장웹엔진 41

1.6.11. Async Servlet 타임아웃처리설정 Servlet 3.0부터추가된 Async Servlet의타임아웃처리를위해서필요한 Thread 개수를설정해야한다. WebAdmin을사용한 Async Servlet 타임아웃처리설정방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Web Engine 화면에서 'Async Timeout Min Threads' 항목을설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 1.28] Async Servlet 타임아웃처리 - Async Timeout Min Threads 설정 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 42 JEUS Web Engine 안내서

5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. Async Servlet 타임아웃처리설정은 동적설정항목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.29] Async Servlet 타임아웃처리 - Async Timeout Min Threads 설정적용결과 제 1 장웹엔진 43

1.6.12. 웹엔진레벨의프로퍼티설정 WebAdmin 을사용해서 JEUS 에서정의한프로퍼티들을설정할수있다. 웹엔진프로퍼티에대한자세한 내용은 JEUS Reference Book 의 1.6. 웹엔진프로퍼티 를참고한다. WebAdmin을사용한프로퍼티설정방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Basic] 메뉴를선택한다. ([ 그림 1.7] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 다음과같이 'Properties' 항목을설정한다. 프로퍼티이름과값을등호 (=) 로연결한후행으로구분하여이름과값의쌍으로입력한다. 입력이완료되면 [ 확인 ] 버튼을클릭한다. [ 그림 1.30] 웹엔진프로퍼티 - 설정 참고 WebAdmin 을사용한프로퍼티설정은 'Properties' 항목을통해설정하는것을권장한다. 그러나 [Servers] > [Basic] > [Basic Info] 메뉴의 'Jvm Option' 항목을통한설정도가능하다. 44 JEUS Web Engine 안내서

4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. ([ 그림 1.5] 참고 ) 5. 설정내용이반영되면다음과같이화면에반영결과가나타난다. 프로퍼티설정은동적설정항목이아니므로반영결과에표시된것처럼서버를재시작해야설정내용이반영된다. [ 그림 1.31] 웹엔진프로퍼티 - 설정적용결과 제 1 장웹엔진 45

1.6.13. 웹공격대응설정 사용자가악의적인목적으로 JEUS에요청처리부담을주기위해일정크기이상의요청들을대량으로보내는공격을받으면정상적인요청들의응답이늦어지거나요청을처리하지못하게되는현상이발생한다. 이런현상을방지하기위하여 JEUS 관리자가 JEUS 서버를기준으로악의적인요청에대한기준을설정하여, 이들의요청처리로인한서버의부담을덜어줄수있다. 이설정들은기본적으로서버의웹엔진내부에설정되며, 웹엔진의요청을받아들이는리스너나커넥터별로설정한다. 즉, HTTP 요청을받아들이는 HTTP 리스너, WebtoB 커넥터, AJP13 커넥터별로설정한다. 각리스터나커넥터별설정은 2.3.1. 리스너공통설정 을참고한다. 제한하려는웹공격에대해다음의설정들을적절하게조합하여설정하면웹공격에대응할수있다. WebAdmin을사용한웹공격대응설정방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. 웹커넥션목록에서웹커넥션을선택한다. [ 그림 1.32] 웹공격대응 - 메뉴이동 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 46 JEUS Web Engine 안내서

3. 다음과같이고급선택사항에 Http Listener 설정영역에서각항목을설정한다. 화면에표시된항목의설정을통해각리스너별로웹공격에대하여대응을할수있다. 각설정항목에대한자세한설명은 2.3.1. 리스너공통설정 을참고한다. [ 그림 1.33] 웹공격대응 - 고급선택사항설정 1.7. 웹엔진튜닝 웹엔진의최적화된성능을위해서는다음의몇가지사항을고려해야한다. 일반적으로 JSP 엔진의컴파일러는변경할필요가없다. JEUS 7부터는 JDK 6에서제공하는 Compiler API를사용해서컴파일한다. <check-included-jspfile> 는 include된 JSP들이자주변경되지않는다면설정을 false로유지한다. 이것은 include된 JSP 파일들에대한변경점검을하지않기때문에성능향상에도움이된다. 제 1 장웹엔진 47

제 2 장웹커넥션관리 본장에서는웹엔진에서제공하는리스너또는커넥터의관리및설정방법등에대해설명한다. 2.1. 개요 JEUS에서는웹리스너와웹커넥터를통칭해서웹커넥션이라고한다. JEUS 7부터는연결을생성하는주체에따라서리스너와커넥터라는개념으로분리하였다. 웹엔진에서는 WebtoB 및다른웹서버와의커넥션, HTTP/TCP 클라이언트와의직접적인커넥션, 또는 Tmax와의커넥션을제공한다. 웹서버는클라이언트의 HTTP 요청을받아조건에맞는경우웹엔진으로요청을전달한다. 대표적인웹서버로 WebtoB와 Apache를사용하고연결을위해다음과같은각각의커넥터를제공한다. WebtoB 커넥터 WebtoB는연결을생성할때 JEUS가클라이언트역할을하기때문에 WebtoB 커넥터를제공한다. AJP 리스너 Apache는 JEUS가서버역할을하기때문에 AJP Listener를제공한다. AJP의경우 IIS, SunOne(Iplanet) 웹서버와같은타사상용웹서버에서도지원하므로 AJP Listener를통해서해당웹서버와연결할수있다. 웹엔진은클라이언트와직접커넥션을맺고, 관리를위해각각의클라이언트별로다음과같은리스너및커넥터를제공한다. HTTP 리스너 HTTP 클라이언트와의직접적인커넥션관리를위해제공한다. TCP 리스너 TCP 클라이언트와의커넥션관리를위해제공한다. Tmax 커넥터 Tmax와의연동을위한커넥터로 WebtoB 커넥터와마찬가지로연결을생성할때에는 JEUS가클라이언트역할을한다. 리스너는 JEUS 서버의설정을기반으로동작한다. 따라서보안 (SSL) 리스너를사용하려면 JEUS 서버에해당설정을하고이를각각의웹관련리스너들이사용하도록설정한다. 참고 JEUS 서버와관련된세부설정사항에대한자세한내용은 JEUS Server 안내서 의 2.3.2. Listener 설정 을참고한다. 제 2 장웹커넥션관리 49

2.2. 구성요소 본절에서는웹엔진에서제공하는리스너및커넥터와사용되는 Thread Pool 에대해설명한다. 2.2.1. 리스너 리스너는 AJP 프로토콜을따르는웹서버, HTTP/TCP 클라이언트가접근할수있는웹엔진의채널이다. 웹엔진의리스너와각클라이언트, 프로토콜의연결을나타내면다음과같다. [ 그림 2.1] 웹엔진의리스너 Server HTTP Client A HTTP protocol Port 80 AJP protocol Port x AJP Listener Web Engine HTTP Client B Web Server(Apache, IIS,...) HTTP protocol Port y HTTP Listener TCP Client TCP protocol Port z TCP Listener 다음은각리스너에대한설명이다. AJP 리스너 WebtoB 이외의다른웹서버 (Apache, IIS, SunOne(Iplanet) 등 ) 를사용할경우에도 JEUS 웹애플리케이션과의상호적인연동이가능하도록하는프로토콜이다. mod_jk module을통해지원하며 AJP1.3 프로토콜을사용한다. AJP 리스너는 SSL을지원한다. AJP 리스너에대한자세한내용은 2.3.2. AJP 리스너설정 과 2.4. 부하분산을위한웹서버설정 을참고하고, AJP 리스너에서사용할 SSL 서버리스너의설정은 "JEUS Server 안내서 " 를참고한다. HTTP 리스너 HTTP 요청을웹엔진이직접받을때사용한다. HTTP 리스너는 SSL을지원한다. HTTP 리스너설정의자세한내용은 2.3.3. HTTP 리스너설정 을참고한다. HTTP 리스너에서사용할 SSL 서버리스너의설정은 "JEUS Server 안내서 " 를참고한다. TCP 리스너 HTTP 프로토콜이아닌커스텀프로토콜로동작하는클라이언트에대한리스너이다. TCP 리스너에대한자세한내용은 2.3.4. TCP 리스너설정 과 2.5. TCP 리스너사용 을참고한다. 50 JEUS Web Engine 안내서

2.2.2. 커넥터 커넥터는웹엔진에서 WebtoB 및 Tmax에연결하기위한채널이다. 웹엔진의커넥터와각클라이언트, 프로토콜의연결을나타내면다음과같다. [ 그림 2.2] 웹엔진의커넥터 Server HTTP Client HTTP protocol Port 80 WJP protocol Web Engine WJP(WebtoB) Connector Port x WebtoB Tmax Client Tmax protocol Port k Tmax-Web Engine protocol Port y Tmax Connector Tmax 다음은각커넥터에대한설명이다. WebtoB 커넥터 WebtoB는 TmaxSoft에서제공하는웹서버이다. JEUS에내장된것을사용하거나별도의제품으로구매해서 JEUS와함께사용할수도있다. WebtoB 커넥터는커넥션생성시점에 JEUS가클라이언트입장이기때문에직접 WebtoB로접속하는특징을가진다. 이런특징에따라방화벽밖에 WebtoB 서버가있을경우에는특별한방화벽설정없이연결을맺을수있다. 이것은방화벽이주로외부로부터의연결시도를억제하고내부로부터의연결은가능하게하는속성을이용한것이다. WebtoB 커넥터에대한자세한내용은 2.4. 부하분산을위한웹서버설정 을참고한다. Tmax 커넥터 Tmax는분산환경에서 XA 트랜잭션을관리하는시스템소프트웨어이다. Tmax 커넥터역시 WebtoB 커넥터와마찬가지로 JEUS가클라이언트역할을한다. Tmax 커넥터는 JEUS와 Tmax 사이의정보를주고받거나, HTTP 요청을 Tmax의게이트웨이를통해받음으로써통신채널을일원화하는용도로사용할수있다. Tmax 커넥터에대한자세한내용은 2.3.6. Tmax 커넥터설정 을참고한다. 참고 JEUS가클라이언트역할을하는것은연결해서커넥션을맺을때뿐이다. 실제로외부클라이언트의요청은 WebtoB, Tmax로부터전달받는것이며, JEUS 내부적으로 WebtoB나 Tmax에요청을보내는경우는없다. 즉, 실제서비스중에는 JEUS가서버역할을한다. 제 2 장웹커넥션관리 51

2.2.3. Worker Thread Pool 리스너또는커넥터에는클라이언트로의요청을처리하기위한 Worker Thread Pool이존재하는데, 이는 Worker Thread들을관리하는개체이다. 리스너의경우요청이오면그요청을처리하기위한 Worker Thread가할당된다. 커넥터의경우 WebtoB 또는 Tmax와 1:1로커넥션을맺고거기에 Worker Thread가할당된다. Worker Thread Pool의최솟값, 최댓값등은서비스처리성능에큰영향을미치기때문에리스너또는커넥터를설정할때는 Worker Thread Pool을주의해서설정해야한다. 참고 JEUS v7.0 Fix#1부터는웹엔진모니터링 Thread에서 Thread Pool 관리작업을수행한뒤그결과를 Logging하지않는다. 각 Thread Pool이자신의상태를직접관리하며, 모니터링 Thread는주기적으로그결과만 Logging해주는방식으로변경되었다. 따라서로그에남겨진 Thread 수증감변화와실제 Thread Pool의상태변화가서로일치하지않을수있으니주의한다. Active-Management 와상태통보 Worker Thread Pool에는 Active-Management에관한설정이포함되어있다. Active-Management는관리자가지정한특정상태에이르면웹엔진이경고메시지를이메일 (e-mail) 로통지하거나웹엔진이속한서버의재시작을권고하는설정이다. 설정가능한값은 Worker Thread가 Block되었다고판단하는기준시간이다. 이에따라 Block된 Worker Thread가증가할경우몇개이상이면경고이메일또는엔진재시작권고메시지출력과같은특정작업의수행을설정한다. 주의 재시작권고가출력되면서버의요청처리가순조롭지못할가능성이크기때문에관리자는메시지 를확인하여서버의재시작여부를판단해야한다. 2.3. 웹커넥션설정 AJP 리스너, WebtoB 커넥터, Tmax 커넥터를사용하는경우각연동제품별로설정이필요하다. 모든웹커넥션은웹엔진에서관리하므로본절에서는웹엔진의설정에대해서만설명한다. WebtoB와다른웹서버의해당설정에대한자세한내용은 2.4. 부하분산을위한웹서버설정 에서설명한다. 참고 1. JEUS 7부터는컨텍스트그룹이없어졌다. 컨텍스트그룹이관리하던대부분의사항들은웹엔진이관리한다. 2. JEUS 7부터는웹리스너의경우서버에서제공하는통합된서비스리스너를사용한다. 따라서 AJP, HTTP, TCP 리스너의경우서버에리스너를설정을하고, 그서버리스너를참조하는방식으로설정한다. 이에따라 'Server Listener Ref' 라는설정이추가되었다. 하지만 WebtoB, Tmax에대한커넥터는 JEUS가클라이언트로서직접연결하므로기존설정방식을유지한다. 52 JEUS Web Engine 안내서

커넥터의추가, 수정, 삭제는 WebAdmin 과콘솔툴을사용할수있다. 커넥터를설정할때에는 WebAdmin 을사용할것을권장한다. WebAdmin 을사용한설정방법은본절에서설명한다. 콘솔툴을사용하여설 정하는방법은 JEUS Reference Book 의 4.2.8. 웹엔진관련명령어 를참고한다. 2.3.1. 리스너공통설정 본절에서는각리스너에서공통적으로사용하는주요설정이다. Name 웹커넥션을식별하는유일한이름이다. 웹엔진내에서유일해야하고, 반드시설정해야한다. Server Listener Ref 해당리스너가참조하는서버리스너를나타낸다. HTTP, AJP 리스너의경우서로같은서버리스너를공유할수있다. 단, HTTP 리스너를관리목적으로사용하겠다고설정한경우에는함께사용할수없다. 설정하지않은경우에는서버의기본리스너를사용한다. TCP 리스너는함께사용할수없다. 2개이상의같은프로토콜리스너를함께사용할수없다. 예를들어 AJP 리스너를 2개설정했는데둘다이설정이없으면서버기본리스너를공유하게되므로설정에러가발생한다. 둘중하나는반드시별도의서버리스너를참조해야한다. Connection Type 각리스너또는커넥터를통해나가는응답의 "Connection" 헤더를강제로설정한다. 다음중하나를설정할수있다. 설정값 keep-alive close none 설명응답을보낸후에도연결을계속유지하고자할경우설정한다. 응답을보낸후연결을끊고자할경우설정한다. 요청헤더에정의된속성에따라응답의 "Connection" 헤더를따르고자할경우설정한다. 웹엔진은아무설정도하지않을경우 'none' 으로설정된것과같이동작한다. AJP 리스너의경우 'Connection Type' 항목을설정할수없다. AJP 리스너는 Apache와같은웹서버의설정을따를것을권장한다. Thread Pool Worker Thread Pool에대한설정이다. 단, WebtoB 커넥터의경우이공통설정을사용하지않고, WebtoB 커넥터만의 Thread Pool 설정을한다. 다음은세부사항을설정하는하위항목에대한설명이다. 제 2 장웹커넥션관리 53

항목 Min Max Step Maximum Idle Time 설명 Pool에서관리할최소 Worker Thread의개수이다. Pool에서관리할최대 Worker Thread의개수이다. 더이상사용하지않는설정이다. Pool 내에존재하던 Thread가제거되기전까지의사용되고있지않은시간을지정한다. 그결과시스템리소스는증가한다. 각 Worker Thread Pool은 Request Wait Queue를가지고있다. 이 Queue는실제가용한 Worker Thread보다많은요청이들어올때사용된다. 이 Queue는소켓리스너에의해유지되는낮은레벨의 Backlog Queue보다상위레벨의 Queue 이다. 다음의두항목은이 Queue와관련된것들이다. Max Wait Queue Max Queue 더많은 Worker Thread가 Pool에생성되기전에얼마나많은요청들이 Request Wait Queue에존재할수있는지에대해결정한다. 몇개의 Thread가증가될지는 step 설정에서정의된다. (Deprecated since JEUS v7.0 Fix#1) Queue에대기할수있는요청의최대개수를설정한다. 이 Queue가가득찬후에더많은요청이도착하면 busy 페이지가클라이언트에게반환된다. 각 Thread Pool은장애가발생했을때취하는액션을정의하는 Thread State Notify 항목을가지고있다. 이것에대해서는다음하위절들을참고한다. 값이 -1일경우 Queue 크기에제한을두지않는것을의미한다 (Blocking 방식의리스너의경우 ). 만약 Listener가 NIO(Non-blocking I/O) 방식을사용한다면엔진내부적으로 Bounded Queue를사용하므로항상 0보다커야한다. NIO(Nonblocking I/O) 방식에서 0보다같거나작은값을설정한경우는기본값인 4096을사용한다. Tmax 커넥터의경우이설정은의미가없다. Output Buffer Size 애플리케이션이사용하는응답버퍼크기값이다. 버퍼가가득차면해당버퍼의내용을웹엔진이자동적으로플러쉬한다. ( 단위 : Byte) AJP 리스너의경우이값을 mod_jk 의 workers.properties 파일의 max_packet_size와일치시키는것이바람직하다. mod_jk 의설정에대해서는 2.4. 부하분산을위한웹서버설정 을참고한다. Postdata Read Timeout postdata를읽어들일때기다릴수있는최대시간을설정한다. ServletRequest.getInputStream().read() 메소드에서적용한다. ( 단위 : ms) Max Post Size 너무큰크기의 POST 요청의데이터가들어와이데이터를읽고분석하고처리하는데많은부하가걸려다른요청들의처리에장애가생길경우를위한설정이다. 이설정을통해특정크기이상의요청에대한처리부담을줄일수있다. ( 기본값 : -1) 54 JEUS Web Engine 안내서

이설정은 POST 요청의경우요청의 Content-type에따라데이터의최대크기를 Byte 단위로제한한다. Content-Type이 x-www-form-urlencoded일경우요청에따라오는데이터의 Byte 크기가설정된값을초과할경우 chunked일경우들어온데이터의크기의합이설정된값보다클경우에 JEUS는해당요청은처리하지않고 "413 Request entity too large" 응답을보내고해당요청처리를완료한다. Content-Type이 multipart/form-data일경우이설정으로업로드파일의크기와 POST 요청의전체크기를제한할수있다. 만약업로드파일을포함한크기를제한하고자한다면 Servlet 3.0의 multipart 관련설정을이용할것을권장한다. 이설정의적용여부는 Servlet 3.0 웹애플리케이션 DD의설정에영향을받는다. 즉, 설정에따라다음과같이동작하게된다. web.xml에 <multipart-config> 의설정여부에따른동작 web.xml에 <multipart-config> 설정이존재할경우이설정의 <max-file-size> 와 <max-request-size> 가적용된다. <multipart-config> 설정이없을경우에는이에대한제한을웹엔진에서는제공하지않는다. 따라서각애플리케이션에서설정해서사용하길권장한다. <content-length> 의설정여부에따른동작 <content-length> 가설정되어있다면이값이설정값을초과할경우요청처리가제한이된다. <content-length> 가설정되어있지않은요청의경우에는이름 / 값쌍의파라미터의 Byte 합이설정값을초과할때요청처리가제한이된다. 음수로설정한경우에는기본값으로설정한것과같이동작하며데이터크기의제한이없다. 이설정은 HTTP 요청을받는리스너및커넥터의경우만의미가있다 (TCP 리스너와 Tmax 커넥터의경우의미가없다 ). Max Parameter Count 하나의요청에너무많은이름 / 값쌍 ( 파라미터 ) 이포함되어, 이파라미터들을분석및관리하는부담이증가하는것을방지하고자할경우설정한다. ( 기본값 : -1) GET과 POST 요청에포함된 ' 이름 / 값 ' 쌍즉, 파라미터의총개수를설정값으로제한한다. GET 요청의 query string, POST 요청의데이터나 multipart/form에이름 / 값쌍으로들어온모든파라미터의개수가설정값이상이넘을경우 "413 requesy entity too large" 응답을보내고, 해당요청의처리를중단한다. 음수로설정한경우에는기본값으로설정한것과같이동작하며파라미터개수의제한이없다. 이설정은 HTTP 요청을받는리스너및커넥터의경우만의미가있다 (TCP 리스너와 Tmax 커넥터의경우의미가없다 ). Max Header Count 하나의요청에포함된헤더가무수히많을경우이요청을읽는부하가많이걸린다. 따라서이럴경우해당요청을거부하여서버의부하를줄일수있다. ( 기본값 : -1) 제 2 장웹커넥션관리 55

설정된값이상의헤더개수가포함된요청은처리하지않고, "400 Bad request" 응답을보낸후해당연결을끊는다. 즉, 헤더이후의데이터는읽지않고버림으로써서버의부담을줄이게된다. 음수로설정한경우에는기본값으로설정한것과같이동작하며, 헤더개수의제한이없다. 이설정은 HTTP 요청을받는리스너및커넥터의경우만의미가있다 (TCP 리스너와 Tmax 커넥터의경우의미가없다 ). Max Header Size 하나의요청에포함된헤더가제한없이클경우이헤더를읽고처리하는데많은부하가걸린다. 따라서이럴경우해당요청을거부하여서버의부하를줄일수있다. ( 기본값 : -1) 설정값보다 Byte 크기 ( 이때헤더의 Byte는요청의헤더하나를타나내는헤더이름, 구분자, 헤더값을모두포함한크기 ) 가큰헤더가포함된요청은처리하지않고 "400 Bad request" 응답을보낸후해당연결을끊는다. 즉, 헤더이후의데이터는읽지않고버림으로써서버의부담을줄이게된다. 음수로설정한경우에는기본값으로설정한것과같이동작하며, 헤더 Byte의제한이없다. 이설정은 HTTP 요청을받는리스너및커넥터의경우만의미가있다 (TCP 리스너와 Tmax 커넥터의경우의미가없다 ). Max Querystring Size GET 요청의 query string이길경우이를분석및관리하는부하가발생할수있다. 이런경우 query string 의크기를제한하여부하를줄일수있다. ( 기본값 : 8192, 단위 : Byte) 설정된 Byte 이상으로큰 query string을포함한요청이들어올경우해당요청에대해 "400 Bad Rqeust" 응답을보낸후해당요청의나머지데이터들은읽지않고버림으로써서버의부하를줄인다. 음수로설정한경우는 qurey string의크기에제한을두지않는다. 그러나 JEUS는내부적으로 request line ( 요청의첫줄 ) 의크기를 64KB로제한하므로그이상은의미가없다. 이설정은 HTTP 요청을받는리스너및커넥터의경우만의미가있다 (TCP 리스너와 Tmax 커넥터의경우의미가없다 ). 2.3.2. AJP 리스너설정 WebAdmin 과콘솔툴을사용하여 AJP 리스너를추가하거나수정및삭제할수있다. WebAdmin 사용 추가및수정다음은 WebAdmin을사용하여 AJP 리스너를추가및수정하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. 56 JEUS Web Engine 안내서

[ 그림 2.3] AJP 리스너추가및수정 - 추가 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. AJP 리스너를추가하려면 [AJP13] 버튼을클릭하고, 수정하려면웹커넥션목록에서 'ajp13' 타입의리스너를클릭한다. Ajp 13 Listener 화면으로이동하면기본정보를설정한다. [ 그림 2.4] AJP 리스너추가및수정 - 일반설정 참고 AJP 리스너는 AJP 버전 1.3 을준수한다. 제 2 장웹커넥션관리 57

4. Thread Pool 영역에서리스너에할당될 Thread Pool 에대해설정한다. [ 그림 2.5] AJP 리스너추가및수정 - Thread Pool 설정 Thread State Notify 에서리스너에할당된 Thread 들의자동상태통보에대한설정을한다. 이설정 에대한자세한설명은 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통보 ) 을참고한다. [ 그림 2.6] AJP 리스너추가및수정 - Thread State Notify 설정 58 JEUS Web Engine 안내서

5. 고급선택사항의항목들을설정한다. 웹공격대응을비롯한몇가지설정이포함되어있다. [ 그림 2.7] AJP 리스너추가및수정 - 고급선택사항설정설정 다음은설정항목에대한설명이고, 나머지설정항목에대한설명은 2.3.1. 리스너공통설정 을참 고한다. 항목 Read Timeout Server Access Control Allowed Server 설명웹서버로부터요청을읽을때적용하는타임아웃이다. ( 단위 : ms) 접근제한기능사용여부를설정한다. 허용하려는웹서버의 IP 주소를설정한다. 입력할주소가하나이상일경우에는행으로구분한다. 'Server Access Control' 항목이체크 (true) 된경우에적용된다. 6. 설정을완료한후 [ 확인 ] 버튼을클릭하면다음과같이 'ajp13' 타입의리스너가추가된것을확인할 수있다. 제 2 장웹커넥션관리 59

[ 그림 2.8] AJP 리스너추가및수정 - 설정확인 7. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭하면다음과같은결과 메시지를확인할수있다. [ 그림 2.9] AJP 리스너추가및수정 - 설정적용결과 60 JEUS Web Engine 안내서

삭제다음은 WebAdmin을사용해서 AJP 리스너를삭제하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. [ 그림 2.10] AJP 리스너삭제 - 메뉴이동 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 삭제할리스너의 [DEL] 버튼을클릭한다. 제 2 장웹커넥션관리 61

[ 그림 2.11] AJP 리스너삭제 - 선택 4. 선택한리스너가삭제되면다음과같이메시가출력된다. [ 그림 2.12] AJP 리스너삭제 - 삭제확인 5. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수 있다. ([ 그림 2.9] 참고 ) 62 JEUS Web Engine 안내서

콘솔툴사용 다음은콘솔툴을사용해서 AJP 리스너를추가, 수정, 삭제하는방법이다. 추가콘솔툴을사용하여 AJP 리스너를추가하려면 add-web-listener 명령을실행한다. add-web-listener 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.8. add-web-listener 를참고한다. add-web-listener [-cluster <cluster-name> -server <server-name>] -name <web-connection-name> -tmin <minimum-thread-num> [-tmax <maximum-thread-num>] [-ajp -http -tcp] -slref <server-listener-ref-name> [-dcc <dispatcher-config-class>] 수정콘솔툴을사용하여 AJP 리스너를수정하려면 modify-web-listener 명령을실행한다. modify-web-lis tener 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.20. modify-web-listener 를참고한다. modify-web-listener [-cluster <cluster-name> -server <server-name>] -name <web-connection-name> [-tmin <minimum-thread-num>] [-tmax <maximum-thread-num>] [-tidle <max-idle-time>] [-obuf <output-buffer-size>] 삭제콘솔툴을사용하여 AJP 리스너를삭제하려면 remove-web-listener 명령을실행한다. remove-weblistener 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.30. remove-web-listener 를참고한다. remove-web-listener [-cluster <cluster-name> -server <server-name>] <web-connection-name> 제 2 장웹커넥션관리 63

2.3.3. HTTP 리스너설정 WebAdmin과콘솔툴을사용하여 HTTP 리스너를추가하거나수정및삭제할수있다. HTTP 리스너는내부관리용도로만사용할것을권장한다. WebAdmin 사용 추가및수정다음은 WebAdmin을사용해서 HTTP 리스너를추가및수정하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.3] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. HTTP 리스너를추가하려면 [HTTP] 버튼을클릭하고, 수정하려면웹커넥션목록에서 'http' 타입의리스너를클릭한다. Http Listener 화면으로이동하면기본정보들을설정한다. [ 그림 2.13] HTTP 리스너추가및수정 - 일반설정 4. Thread Pool 영역의설정은 AJP 리스너와동일하므로설정화면은 2.3.2. AJP 리스너설정 을참고 하고, Thread State Notify 설정에대한자세한내용은 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통보 ) 을참고한다. 64 JEUS Web Engine 안내서

5. 고급선택사항의항목을설정한다. [ 그림 2.14] HTTP 리스너추가및수정 - 고급선택사항설정 다음은설정항목에대한설명이고, 나머지설정항목에대한설명은 2.3.1. 리스너공통설정 을참 고한다. 항목 Server Access Control Allowed Server 설명접근제한기능사용여부를설정한다. 허용하려는 HTTP 클라이언트의 IP 주소를설정한다. 입력할주소가하나이상일경우에는행으로구분한다. 'Server Access Control' 항목이체크 (true) 된경우에적용된다. 제 2 장웹커넥션관리 65

6. 설정을완료한후 [ 확인 ] 버튼을클릭하면다음과같이 'http' 타입의리스너가추가된것을확인할수 있다. [ 그림 2.15] HTTP 리스너추가및수정 - 추가확인 7. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수있다. ([ 그림 2.9] 참고 ) 삭제다음은 WebAdmin을사용해서 HTTP 리스너를삭제하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.10] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 66 JEUS Web Engine 안내서

3. 삭제할리스너의 [DEL] 버튼을클릭한다. [ 그림 2.16] HTTP 리스너삭제 - 선택 4. 선택한리스너가삭제되면다음과같이메시지가출력된다. [ 그림 2.17] HTTP 리스너삭제 - 삭제확인 5. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수 있다. ([ 그림 2.9] 참고 ) 제 2 장웹커넥션관리 67

콘솔툴사용 콘솔툴을사용하여 HTTP 리스너를추가, 수정, 삭제하는방법은 AJP 리스너의방법과동일하다. 자세한 내용은 2.3.2. AJP 리스너설정 의 " 콘솔툴사용 " [63] 부분을참고한다. 2.3.4. TCP 리스너설정 TCP 리스너는커스텀프로토콜로상호간에통신할수있도록제공하는특수한리스너이다. TCP 리스너는기본적으로서버리스너를다른웹리스너들과공유할수없기때문에사용을위해서는서버에 TCP 리스너를위한전용리스너를추가해야한다. WebAdmin과콘솔툴을사용하여 TCP 리스너를추가하거나수정및삭제할수있다. WebAdmin 사용 추가및수정다음은 WebAdmin을사용해서 TCP 리스너를추가및수정하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.3] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. TCP 리스너를추가하려면 [TCP] 버튼을클릭하고, 수정하려면웹커넥션목록에서 'tcp' 타입의리스너를클릭한다. Tcp Listener 화면으로이동하면기본정보들을설정한다. [ 그림 2.18] TCP 리스너추가및수정 - 일반설정 68 JEUS Web Engine 안내서

다음은설정항목에대한설명이고, 그외의나머지항목에대한설명은 2.3.1. 리스너공통설정 을 참고한다. 항목 Dispatcher Config Class 설명 Dispatcher Config Class의이름을설정한다. Dispatcher Config Class는 TCP 리스너와해당클라이언트사이에서정의된프로토콜을정의한클래스이다. jeus.servlet.tcp.tcpdispatcherconfig 인터페이스를구현한정식클래스이름을정의한다. Dispatcher Config Class가없을경우에는 TCP 리스너가동작하지않고, 구현된클래스는반드시 JEUS_HOME/lib/application 아래에위치해야한다. 웹엔진에 deploy할웹컨텍스트에는 jeus.servlet.tcp.tcpservlet을구현한클래스를포함해야하며 web.xml에매핑해야한다. 자세한내용은 2.5. TCP 리스너사용 을참고한다. 4. Thread Pool 영역의설정은 AJP 리스너와동일하므로설정화면은 2.3.2. AJP 리스너설정 을참고하고, Thread State Notify 설정에대한자세한내용은 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통보 ) 을참고한다. 5. 고급선택사항의항목을설정한다. [ 그림 2.19] TCP 리스너추가및수정 - 고급선택사항설정 다음은설정항목에대한설명이고, 나머지설정항목에대한설명은 2.3.1. 리스너공통설정 을참 고한다. 제 2 장웹커넥션관리 69

항목 Servers Adccess Control Allowed Server 설명 접근제한기능사용여부를설정한다. 허용하려는웹서버의 IP 주소를설정한다. 입력할주소가하나이상일경우에는행으로구분한다. 'Server Access Control' 항목이체크 (true) 된경우에적용된다. 6. 설정을완료한후 [ 확인 ] 버튼을클릭하면다음과같이 'tcp' 타입의리스너가추가된것을확인할수 있다. [ 그림 2.20] TCP 리스너추가및수정 - 추가확인 7. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수있다. ([ 그림 2.9] 참고 ) 삭제다음은 WebAdmin을사용해서 TCP 리스너를삭제하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.10] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 70 JEUS Web Engine 안내서

3. 삭제할리스너의 [DEL] 버튼을클릭한다. [ 그림 2.21] TCP 리스너삭제 - 선택 4. 선택한리스너가삭제되면다음과같이메시지가출력된다. [ 그림 2.22] TCP 리스너삭제 - 삭제확인 5. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수 있다. ([ 그림 2.9] 참고 ) 제 2 장웹커넥션관리 71

콘솔툴사용 콘솔툴을사용하여 TCP 리스너를추가, 수정, 삭제하는방법은 AJP 리스너의방법과동일하다. 자세한 내용은 2.3.2. AJP 리스너설정 의 " 콘솔툴사용 " [63] 부분을참고한다. 2.3.5. WebtoB 커넥터설정 WebtoB 커넥터는커넥션을생성할때 JEUS가클라이언트역할을하게된다. 따라서 WebtoB 주소와연결포트가필요하다. WebAdmin과콘솔툴을사용하여 WebtoB 커넥터를추가하거나수정및삭제할수있다. WebAdmin 사용 추가및수정다음은 WebAdmin을사용해서 WebtoB 커넥터를추가및수정하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.3] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. WebtoB 커넥터를추가하려면 [WEBTOB] 버튼을클릭하고, 수정하려면웹커넥션목록에서 'webtob' 타입의커넥터를클릭한다. Webtob Connector 화면으로이동하면기본정보들을설정한다. [ 그림 2.23] WebtoB 커넥터추가및수정 - 기본설정 72 JEUS Web Engine 안내서

다음은설정항목에대한설명이고, 그외의나머지항목에대한설명은 2.3.1. 리스너공통설정 을 참고한다. 항목 Hth Count Registration Id 설명 WebtoB 설정파일의 NODE 절에지정된 HTH 프로세스개수와일치해야한다. 2.4. 부하분산을위한웹서버설정 을참고한다. WebtoB 설정파일의 SERVER 절의값과일치해야한다. 15자이내로설정한다. 4. Network Address와 Domain Socket Address 영역의항목을서로배타적으로설정한다. 한항목을설정하면다른항목은설정할수없다. Network Address에 WebtoB 서버와연결할포트와 IP 주소를설정한다. 만약, Network Address의설정을사용하지않으려면 Domain Socket Address를설정해야한다. 이것은 UNIX 도메인소켓또는 Windows에서 HTH 프로세스와 IPC 통신을사용할때설정한다. 즉, WebtoB가같은머신에있을때만의미가있다. [ 그림 2.24] WebtoB 커넥터추가및수정 - 연결설정 5. Thread Pool 영역에서 WebtoB로부터온 HTTP 요청을처리할 Worker Thread에대해설정한다. JEUS 6까지는 Worker Thread의최솟값과최댓값을설정하였으나, 이설정값들이실제동작에의미가없어 Worker Thread의수를설정하는 'Number' 로통일하였다. [ 그림 2.25] WebtoB 커넥터추가및수정 - Thread Pool 설정 제 2 장웹커넥션관리 73

다음은설정항목에대한설명이다. 항목 Number 설명 Worker Thread의개수로, WebtoB로연결된소켓의수와같다. 그러므로 WebtoB 설정의 'MinProc' 과 'MaxProc' 값을참고하여웹엔진에서 WebtoB로연결할수를설정한다. 'MinProc' 과 'MaxProc' 에대한자세한내용은 2.4.4. WebtoB와의부하분산설정 을참고한다. Thread State Notify 에서리스너에할당된 Thread 들의자동상태통보에대한설정을한다. 이설정 에대한자세한설명은 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통보 ) 을참고한다. [ 그림 2.26] WebtoB 커넥터추가및수정 - Thread State Notify 설정 74 JEUS Web Engine 안내서

6. 고급선택사항의항목을설정한다. [ 그림 2.27] WebtoB 커넥터추가및수정 - 고급선택사항설정 다음은설정항목에대한설명이고, 그외의나머지항목에대한설명은 2.3.1. 리스너공통설정 을 참고한다. 항목 Request Prefetch 설명 웹엔진측에서요청을처리하는동안다음요청을 WebtoB 로부터미리받아올 것인지설정한다. 기능이활성화되면웹엔진은각 WebtoB Worker Thread마다하나의 Queue를할당하고, Queue는 Worker Thread가현재요청을처리하는동안 WebtoB로부터오는요청을버퍼링한다. 따라서웹엔진은 WebtoB로부터다음요청을받는시간을단축할수있다. 이기능의단점은요청을처리하는도중웹엔진에심각한문제가발생하면 Queue에축적된요청들을잃어버릴수있다는것이다. Read Timeout WebtoB 는지속적으로웹엔진에게 WebtoB 의설정파일에정의된 svrchktime 변수값의간격으로 ping 메시지를보낸다. 웹엔진은여기에서설정된시간간격으로 WebtoB의상태보고결과를체크한다. WebtoB의 ping이여기에서설정된시간간격내에서발견되지않으면통신연결은끊어진것으로간주되어다시설정된다. 그러므로설정값은 svrchktime 변수값보다커야한다. Reconnect Interval WebtoB 와의연결들이끊어지면재연결을시도하는데, 각재연결사이의시간 간격을설정한다. 1 초보다작게설정하는것은의미가없다. ( 기본값 : 5000) 연결이성공할때까지설정한시간간격으로무한히시도한다. 제 2 장웹커넥션관리 75

7. 설정을완료한후 [ 확인 ] 버튼을클릭하면다음과같이 'webtob' 타입의커넥터가추가된것을확인할 수있다. [ 그림 2.28] WebtoB 커넥터추가및수정 - 추가확인 8. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수있다. ([ 그림 2.9] 참고 ) 삭제다음은 WebAdmin을사용해서 WebtoB 커넥터를삭제하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.10] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 76 JEUS Web Engine 안내서

3. 삭제할커넥터의 [DEL] 버튼을클릭한다. [ 그림 2.29] WebtoB 커넥터삭제 - 선택 4. 선택한커넥터가삭제되면다음과같이메시지가출력된다. [ 그림 2.30] WebtoB 커넥터삭제 - 삭제확인 5. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수 있다. ([ 그림 2.9] 참고 ) 제 2 장웹커넥션관리 77

콘솔툴사용 다음은콘솔툴을사용해서 WebtoB 커넥터를추가, 수정, 삭제하는방법이다. 추가콘솔툴을사용하여 WebtoB 커넥터를추가하려면 add-webtob-connector 명령을실행한다. addwebtob-connector 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.9. add-webtob-connector 를참고한다. add-webtob-connector [-cluster <cluster-name> -server <server-name>] -name <web-connection-name> -num <thread-number> -regid <registration-id> [-addr <server-address>] -port <server-port> -dsocket [-wbhome <webtob-home>] [-ipcport <ipc-base-port>] 수정콘솔툴을사용하여 WebtoB 커넥터를수정하려면 modify-webtob-connector 명령을실행한다. modifywebtob-connector 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.21. modify-webtobconnector 를참고한다. modify-webtob-connector [-cluster <cluster-name> -server <server-name>] -name <web-connection-name> [-num <thread-number>] [-obuf <output-buffer-size>] [-addr <server-address>] [-port <server-port>] [-regid <registration-id>] 삭제콘솔툴을사용하여 WebtoB 커넥터를삭제하려면 remove-webtob-connector 명령을실행한다. removewebtob-connector 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.31. remove-webtobconnector 를참고한다. remove-webtob-connector [-cluster <cluster-name> -server <server-name>] <web-connection-name> 2.3.6. Tmax 커넥터설정 Tmax 커넥터역시 WebtoB 커넥터와마찬가지로커넥션을생성할때 JEUS가클라이언트역할을하게된다. 따라서 Tmax 주소와연결포트가필요하다. WebAdmin과콘솔툴을사용하여 Tmax 커넥터를추가하거나설정및삭제할수있다. 78 JEUS Web Engine 안내서

WebAdmin 사용 추가및수정다음은 WebAdmin을사용해서 Tmax 커넥터의추가및설정하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.3] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Tmax 커넥터를추가하려면 [TMAX] 버튼을클릭하고, 수정하려면웹커넥션목록에서 'tmax' 타입의커넥터를클릭한다. Tmax Connector 화면으로이동하면기본정보들을설정한다. [ 그림 2.31] Tmax 커넥터추가및수정 - 기본설정 제 2 장웹커넥션관리 79

다음은설정항목에대한설명이고, 그외의나머지항목에대한설명은 2.3.1. 리스너공통설정 을 참고한다. 항목 Port Reconnect Count For Backup Tmax Address Tmax Version Server Type Xaresource Class Server Group Name Server Name Tmax Backup Address Tmax Backup Port Dispatcher Config Class Selector Count 설명 Tmax와연결할포트로 Tmax 설정파일에서의 JEUS 연결포트값과일치해야한다. Tmax와의연결들이끊어지면재연결을시도하는데총시도횟수를의미한다. 항상 1 이상이며, Backup 설정이있을때만사용한다. ( 기본값 : 12) Tmax 서버의 IP 주소를설정한다. 연결하려는 Tmax 서버의버전을설정한다. 연결하려는 Tmax 서버의종류를설정한다. XAResource 클래스이름을설정한다. Tmax와연결할때 Tmax의어떤서버와연결할것인지를설정해야한다. 이설정은연결할서버가속해있는그룹을나타낸다. 연결하려는 Tmax 서버이름을설정한다. Tmax에장애가발생했을때백업으로동작하는서버의주소이다. 주소와포트만설정하고나머지는 Primary 서버의설정을그대로가져간다. Tmax에장애가발생했을때백업서버에연결할포트번호를설정한다. 'Tmax Backup Address' 가설정되어있다면함께설정해야한다. Dispatcher Config Class를지정한다. 이때클래스는반드시클래스패스로설정된곳에있어야하며, 클래스의이름은 fully qualified class name이어야한다. NIO를사용할때 (use-nio=true) Selector의개수를지정하는설정이다. 기본으로 1 개로설정되며커넥션의개수가많아성능이저하될경우 Selector 개수를적절히증가시켜주면성능이향상될수있다. 4. Thread Pool 영역의설정은 AJP 리스너와동일하므로설정화면은 2.3.2. AJP 리스너설정 을참고 하고, Thread Pool 설정에대한자세한내용은 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통 보 ) 을참고한다. 80 JEUS Web Engine 안내서

5. 고급선택사항의항목을설정한다. [ 그림 2.32] Tmax 커넥터추가및수정 - 고급선택사항설정 다음은설정항목에대한설명이고, 그외의나머지항목에대한설명은 2.3.1. 리스너공통설정 을 참고한다. 항목 Reconnect Interval 설명 Tmax 와의연결들이끊어지면재연결을시도하는데, 각재연결사이의시간간 격을설정한다. 1 초보다작게설정하는것은의미가없다. ( 기본값 : 5000) 연결이성공할때까지설정한시간간격으로무한히시도한다. 단, 백업설정이 있으면 'Reconnect Count For Backup' 설정값만큼시도한뒤 Failover 를수행 한다. Use Nio NIO 방식을사용하면커넥션을담당하는 Thread 와 Worker Thread 가분리되어 있어서기존방식에서동시에처리할수있는커넥션개수가 Worker Thread 수 보다작을수밖에없는문제점을해결할수있다. ( 기본값 : false) true 로설정할경우 NIO(Non-blocking I/O) Tmax 커넥터로동작하게된다. 제 2 장웹커넥션관리 81

6. 설정을완료한후 [ 확인 ] 버튼을클릭하면다음과같이 'tmax' 타입의커넥터가추가된것을확인할 수있다. [ 그림 2.33] Tmax 커넥터추가및수정 - 추가확인 7. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면설정적용결과메시지를확인할수있다. ([ 그림 2.9] 참고 ) 삭제다음은 WebAdmin을사용해서 Tmax 커넥터를삭제하는방법이다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Web Connections] 메뉴를선택하면웹커넥션목록조회화면으로이동한다. ([ 그림 2.10] 참고 ) 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 82 JEUS Web Engine 안내서

3. 삭제할커넥터의 [DEL] 버튼을클릭한다. [ 그림 2.34] Tmax 커넥터삭제 - 선택 4. 선택한커넥터가삭제되면다음과같이메시지가출력된다. [ 그림 2.35] Tmax 커넥터삭제 - 삭제확인 제 2 장웹커넥션관리 83

5. 설정내용의반영을위해 [Activate Changes] 버튼을클릭하면다음과같은결과메시지를확인할 수있다. [ 그림 2.36] Tmax 커넥터삭제 - 삭제적용결과 콘솔툴사용 다음은콘솔툴을사용해서 Tmax 커넥터를추가, 수정, 삭제하는방법이다. 추가콘솔툴을사용하여 Tmax 커넥터를추가하려면 add-tmax-connector 명령을실행한다. add-tmaxconnector 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.6. add-tmax-connector 를참고한다. add-tmax-connector [-cluster <cluster-name> -server <server-name>] -name <web-connection-name> -tmin <minimum-thread-num> [-tmax <maximum-thread-num>] -addr <server-address> -port <server-port> -svrg <server-group-name> -svr <server-name> -dcc <dispatcher-config-class> 84 JEUS Web Engine 안내서

수정콘솔툴을사용하여 Tmax 커넥터를수정하려면 modify-tmax-connector 명령을실행한다. modifytmax-connector 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.17. modify-tmax-connector 를참고한다. modify-tmax-connector [-cluster <cluster-name> -server <server-name>] -name <web-connection-name> [-tmin <minimum-thread-num>] [-tmax <maximum-thread-num>] [-tidle <max-idle-time>] [-obuf <output-buffer-size>] [-addr <server-address>] [-port <server-port>] [-svrg <server-group-name>] [-svr <server-name>] 삭제콘솔툴을사용하여 Tmax 커넥터를삭제하려면 remove-tmax-connector 명령을실행한다. removetmax-connector 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.28. remove-tmax-connector 를참고한다. remove-tmax-connector [-cluster <cluster-name> -server <server-name>] <web-connection-name> 2.3.7. 자동 Thread Pool 관리설정 (Thread 상태통보 ) Thread 상태통보는이메일통지나서버재시작권고를위해필요한최소의 Worker Thread 수와관련된오류조건을정의한다. 리스너및커넥터설정화면의 Thread State Notify 영역에서설정한다. 자동 Thread Pool 관리설정이되면 'Max Thread Active Time' 설정값을기준으로 Worker Thread가관리된다. 요청을받아처리를시작한시점부터 Max Thread Active 설정시간을초과한 Thread들은 Blocked Thread 로관리가된다. 그리고 Blocked Thread가아닌일반 Thread들의숫자가 Thread Pool에서설정한최솟값보다작을경우는새로운 Worker Thread를생성하여최솟값을유지할수있게한다. 단, WebtoB 커넥터의경우에는최솟값이없고전체연결숫자만존재하므로다른리스너또는커넥터와는다르게동작한다. WebtoB 커넥터는 Blocked Thread와일반 Thread의숫자의합이설정한연결숫자와같아야한다. 그리고 Blocked Thread의요청처리가끝나는순간 Blocked Thread는삭제되고새로운 Worker Thread에 WebtoB 연결요청을한다. Thread Pool의 Thread 상태변경에대한통보설정을통해원하는통보를받을수있다. 제 2 장웹커넥션관리 85

다음은 AJP 리스너에서이메일알림자를포함하고있는설정예이다. 이메일알림자를통해받을이메일 의설정은 JEUS Server 안내서 의 8.3. Logging 설정 의 SMTP 핸들러설정을참고한다. [ 그림 2.37] 자동 Thread Pool 관리설정 - Thread State Notify 설정 다음과각항목에대한설명이다. 항목 Max Thread Active Time 설명 Block 되기전까지 Worker Thread 가사용될수있는최대시간을설정한다. 이시간은 Worker Thread가클라이언트요청을서비스할때부터측정된다 ( 서블릿이수행될때 ). 설정한시간이초과되었거나또는 Thread가자유롭게되어 Thread Pool로되돌아갈때만료된다 (Thread가 Block되지않는상황 ). 설정값이 0이거나음수이면무시된다. Notify Threshold Ratio 존재할수있는 Blocked Thread 의최대비율을설정한다. 전체 Thread 개수 대비 Blocked Thread 의비율이초과되면, 오류조건으로결정되어이메일알 림자를통하여이메일통보가전송된다. 1 보다작은소숫점으로설정하며, 0 이거나음수이면무시된다. Restart Threshold Ratio 존재할수있는 Blocked Thread의최대비율을설정한다. 전체 Thread 개수대비 Blocked Thread의비율이초과되면, 오류조건으로결정되어이메일알림자를통하여이메일통보가전송된다. 그후에서버로그에서버재시작권고메시지가기록된다. 1 보다작은소숫점으로설정하며, 0 이거나음수이면이설정이무시된다. Notify Subject Restart Subject 경고이메일을전송할때사용된다. 엔진로그및통보할때사용하는이메일에사용된다. 86 JEUS Web Engine 안내서

항목 Interrupt Thread 설명 Active Timeout이발생할때, 즉 Worker Thread가 'Max Thread Active Time' 설정값이상으로요청을처리중일때해당 Thread의 interrupt 발생유무를결정한다. ( 기본값 : false) true 인경우 interrupt 를발생시킨다. Active Timeout Notifica tion Active Timeout 발생이이메일전송여부를결정한다. ( 기본값 : false) true 인경우이메일이전송된다. 2.4. 부하분산을위한웹서버설정 본절에서는 JEUS 와의연동사례가많은웹서버들의설정방법과웹엔진을웹커넥션과연동할수있는 방법에대해서설명한다. 웹엔진은시스템의 HTTP 처리의성능향상을위해웹서버와웹엔진 ( 서블릿엔진 ) 으로구성하여서비스할수있다. 각웹엔진으로의 HTTP 요청을웹엔진앞의웹서버에서 1차로부하를분산시킨다. 이후같은연결이나세션의요청에대해 HTTP 세션클러스터링서비스를이용하여처음요청을처리한웹엔진으로할당하여서비스처리효율을높인다. 처음요청을처리한웹엔진에장애가발생한경우, 장애발생이후에들어온요청은웹엔진앞의웹서버에서장애가발생하지않은웹엔진으로전달하여끊김없는서비스를가능하게한다. 이서비스는 HTTP 세션클러스터링을사용한다는전제조건이필요하다. HTTP 세션클러스터링에대한자세한내용은 JEUS 세션관리안내서 의 제2장분산세션서버 를참고한다. 만약웹서버를사용하지않고웹엔진만을사용할경우에요청을처리한웹엔진으로이후의요청을전달할수있는장비나소프트웨어를사용하면웹서버를사용할때와같이효율적인서비스가가능할것이다. 그러나 JEUS에서는이에필요한소프트웨어를제공하지않고, 이런사용을권장하지않는다. 경고각웹서버들의설정과 mod_jk 설정은웹서버버전에따라서차이가있을수있다. 본절의설정방법은 JEUS 사용자들의이해를돕기위해서제공하는것이므로실제로설정할때에는반드시각웹서버들의문서, 국내외커뮤니티에서제공하는설정사례들을참고해야한다. 2.4.1. 부하분산구조 서비스요청이많은웹사이트는한대의웹서버와웹엔진으로는서비스를제공하기어렵기때문에부하 분산을위해서여러개의웹서버와웹엔진이필요하다. 제 2 장웹커넥션관리 87

다음은 2 대의웹서버와 4 대의웹엔진이연결되어있는부하분산구조를나타낸다. [ 그림 2.38] 소규모웹사이트에서의부하분산구조 Web Engine A Web Connection A Web Engine B Client Requests Load Balancer Web Server A Web Connection B Web Engine C Web Connection C Web Engine D Web Server B Web Connection D 각웹엔진에는동일한웹컨텍스트들이 deploy되어있어야한다. 이러한환경에서중요한것은세션의공유여부이다. 애플리케이션을좀더편리하게관리하고싶거나분산세션서비스가필요하다면웹엔진들을하나의클러스터로묶어야한다. 세션클러스터에대한자세한내용은 JEUS 세션관리안내서 의 제1 장세션트래킹 (Session Tracking) 을참고한다. 2.4.2. Apache 웹서버 Apache를웹엔진과연동하려면다음과같은과정을수행해야한다. 1. Apache에 mod_jk 라이브러리를설치한다. 2. JEUS 웹엔진에 AJP13 리스너를설정한다. 3. workers.properties 파일을생성하고편집한다. 4. Apache 웹서버의 httpd.conf 파일에연동구절을삽입한다. 5. Apache 웹서버를재시작한다. 참고 Apache 의경우 2.2.4, mod_jk 의경우 1.2.20 을기준으로설명한다. 88 JEUS Web Engine 안내서

mod_jk 라이브러리설치 Apache 웹서버를웹엔진의앞단에서사용하려면 "mod_jk" 라는모듈을 Apache 설치모듈에추가해야한다. "mod_jk" 모듈은서버와엔진간의통신프로토콜을구현한것으로, 이프로토콜은 Apache JServ Protocol 1.3(AJP 1.3) 이다. 참고 2014 년 4 월현재 Windows 바이너리를제공하고있는 http://tomcat.apache.org/download-connec tors.cgi 에서소스를다운로드받아서해당머신에서컴파일한다. AJP13 리스너설정 mod_jk 라이브러리설치가완료되면 JEUS 웹엔진에 AJP13 리스너를설정한다. AJP13 리스너설정방 법의자세한내용은 2.3.2. AJP 리스너설정 을참고한다. workers.properties 설정 workers.properties 파일은 mod_jk를위한설정파일이다. 예를들어 JEUS는 server1, server2라는 2대의서버가있다. 호스트이름이각각 server1, server2라고가정하면각서버의웹엔진이름은 server1_servlet, server2_servlet이된다. 각웹엔진에설정된 AJP 리스너들은 9901, 9902로설정했다고가정하자. 다음은가정한 JEUS 환경에서의 workers.properties 예제이다. [ 예 2.1] mod_jk 설정파일예제 : <<workers.properties>> worker.list=jeus_load_balancer_workers worker.jeus_load_balancer_workers.type=lb worker.jeus_load_balancer_workers.balance_workers=server1_servlet, server2_servlet worker.jeus_load_balancer_workers.sticky_session=true ########################################### # listener specific configuration ########################################### worker.server1_servlet.host=server1 worker.server1_servlet.port=9901 worker.server1_servlet.type=ajp13 worker.server1_servlet.route=zg9tywlums9zzxj2zxix worker.server2_servlet.host=server2 worker.server2_servlet.port=9902 worker.server2_servlet.reference=server1_servlet worker.server2_servlet.route=zg9tywlums9zzxj2zxiy 제 2 장웹커넥션관리 89

workers.properties 파일은몇몇정의를제외하고일반적으로 "worker.<worker_name>.<directive>=<val ue>" 의형식으로설정을정의한다. 다음은중요한설정에대한설명이다. worker.list 해당 worker를정의하는항목이다. worker의이름들은콤마 (,) 로구분되며여러 worker들을나열할수있다. 다음은 "jeus_load_balancer_workers" 라는이름의 worker를하나정의한예제이다. worker.list=jeus_load_balancer_workers worker.<worker_name>.type worker의타입을정의한다. 'ajp13', 'ajp14', 'jni', 'lb', 'status' 등을선택할수있다. AJP13을지원하기위해 JEUS에서는 'ajp13', 'lb' 만의설정으로도충분하다. 다음은 "jeus_load_balancer_workers" 를 load balancer type으로정의한예제이다. worker.jeus_load_balancer_workers.type=lb worker.<worker_name>.balance_workers 콤마 (,) 로구분하여 Load Balance를원하는 worker들을나열할수있다. 위의 woker.list에적은 worker 들이나타나서는안된다. JEUS의 AJP13 리스너와연동하는경우올바른 load balancer 및 sticky session 역할을하려면 worker 의이름을 JEUS의서블릿엔진이름으로해야한다. JEUS의경우 Session ID의라우팅정보로서블릿엔진이름을이용하며 mod_jk에서는 worker의이름을이용하기때문이다. worker.<worker_name>.sticky_session Session ID를기반으로라우팅을지원할지여부를설정한다. true(or 1) 또는 false(or 0) 로설정할수있다. JEUS에서는 Sticky Session을기본으로지원하므로항상 true로설정한다. ( 기본값 : true) 다음은 "jeus_load_balancer_workers" 는 Sticky Session을지원한다는예제이다. worker.jeus_load_balancer_workers.sticky_session=true worker.<worker_name>.host JEUS의 AJP13 리스너가존재하는호스트이름또는 IP 주소를입력한다. worker.<worker_name>.port JEUS의 AJP13 리스너의포트번호를설정한다. worker.<worker_name>.reference 많은 load balancer worker들을설정할때유용하며지정된값에해당하는 worker의설정값을 reference 할수있는설정이다. 예를들어 "worker.castor.reference=worker.pollux" 라고설정했다면명시적으로 castor worker에서설정한값을제외하고모든 pollux worker의설정들을상속받는다. worker.<worker_name>.route 90 JEUS Web Engine 안내서

설정값에해당하는값이 sticky로요청이왔을경우에해당 worker가처리하는설정이다. JEUS의세션매니저에서생성하는세션에붙이는세션라우팅기술로해당하는 worker를매치시킴으로서로컬세션의활용도를높일수있다. 세션라우팅에대한자세한내용은 JEUS 세션관리안내서 의 1.2. 세션트래킹구조 를참고한다. 해당값은 domain_name/server_name의 Base64 알고리즘으로인코딩한값이다. 해당인코딩값은 JEUS_HOME/bin의 encryption 명령을통해얻을수있다. 다음은사용예제이다. jeus/bin/encryption -algorithm base64 -text domain1/server1 설정할때 server1_servlet의엔진이름이아닌 "domain1/server1", "domain1/server2" 와같이 " 도매인이름 / 서버이름 " 을사용하는것에유의한다. 경고 이설정들은 mod_jk 버전에따라 deprecated 될수도있으므로본절에서제시한내용은참고용도로 만사용한다. 반드시 Tomcat 홈페이지의 mod_jk 관련설명에따라설정한다. httpd.conf 설정 httpd.conf 파일에는 mod_jk 모듈을사용하기위해다음사항을추가해야한다. [ 예 2.2] Apache에 mod_jk 설정예제 : <<httpd.conf>>... LoadModule jk_module "/usr/local/apache/modules/mod_jk.so" JkWorkersFile "/usr/local/apache/conf/workers.properties" JkLogFile "/usr/local/apache/logs/mod_jk.log" JkLogLevel info JkMount /examples/* jeus_load_balancer_workers... 경고 Apache 버전에따라 deprecated 될수도있으므로여기에서제시한것은참고용도로만사용한다. 반드시 Apache 매뉴얼에따라설정한다. 2.4.3. IIS 웹서버및 Iplanet 웹서버설정 IIS 웹서버와 Iplanet 웹서버도 AJP13 프로토콜을지원한다. 따라서 workers.properties와 JEUS 설정방식은모두동일하다. 단, 각제품에따라 mod_jk 모듈을설치하는방법과 mod_jk 사용설정을하는방법이다르다. 이러한설정방법은각웹서버에서제공하는매뉴얼을참고한다. 제 2 장웹커넥션관리 91

2.4.4. WebtoB 와의부하분산설정 본절에서는예제를통하여 WebtoB와 JEUS의부하분산처리환경을구성한다. 각엔진이각각의 WebtoB 서버를갖는구조에대한설정으로예제는 2대의 WebtoB가각각 2대의웹엔진에연결된다. 다음은예제의서버구조를나타낸다. [ 그림 2.39] 부하분산서버구조 - 2대의 WebtoB가각각 2대의웹엔진에연결된경우 Server A Web Engine WebtoB Listener A Server B Web Engine Client Requests Third-party Load Balancer WebtoB A WebtoB Listener B Server C Web Engine WebtoB Listener C Server D Web Engine WebtoB B WebtoB Listener D Server A부터 D에는동일한웹컨텍스트를 deploy해야한다. 위와같은구성에서는일반적으로 Server A부터 D가하나의클러스터를이루게되며, 그에따라분산식세션서버를사용하게된다. 만약사용자세션이필요없는경우에는클러스터를구성하지않아도무방하다. 92 JEUS Web Engine 안내서

다음은 WebtoB A 와 Server A, Server B 가연결된모습을좀더자세히표현한것으로각각의 WebtoB 커 넥터설정상태를보여준다. [ 그림 2.40] WebtoB 커넥터설정상태 Server A Web Engine Load balancer WebtoB A HTH = 2 HTH 1 MinProc = 25 MaxProc = 25 10 10 15 WebtoB Listener A number threads = 10 Server B Web Engine HTH 2 MinProc = 25 MaxProc = 25 15 WebtoB Listener B number threads = 15 설정할때에는 WebtoB의 HTH 프로세스수를고려해야한다. WebtoB HTH 프로세스는몇개의하위프로세스를가지고있는엔진처럼행동한다. 이는 WebtoB 커넥터의 Worker Thread와 1대 1로연결된다. 따라서 WebtoB 커넥터의 'Worker Thread Pool Max' 설정값과 WebtoB 설정의 'MaxProc' 값을주의해서설정해야한다. HTH 프로세스의개수는 WebtoB 설정에존재하는 HTH 프로세스개수를그대로 WebtoB 커넥터의 'Hth Count' 설정에반영한다. WebtoB의 'MaxProc' 값과 WebtoB 커넥터의 'Worker Thread Pool Max' 값은다음과같은공식으로표현될수있다. MinProc = Listener A number threads + Listener B number threads + + Listener X number threads setting. MaxProc = Listener A number threads + Listener B number threads + + Listener X number threads setting. WebtoB 커넥터의 'Hth Count' 값은 WebtoB 설정파일의 NODE 절의요소중 HTH 프로세스개수와반드시동일해야한다. WebtoB 커넥터설정은 2.3.5. WebtoB 커넥터설정 을참고한다. 다음은 WebtoB A가위의예제와같이설정되기위한 http.m 파일의설정예이다. [ 예 2.3] WebtoB 설정예 : <<http.m>> *NODE foo HTH = 2, JSVPORT = 9900, *SVRGROUP jsvg NODENAME = foo, SVRTYPE = JSV *SERVER 제 2 장웹커넥션관리 93

default SVGNAME = jsvg, MinProc = 6, MaxProc = 25 *URI uri1 Uri = "/examples/", Svrtype = JSV uri2 Uri = "/test/", Svrtype = JSV *EXT jsp MimeType = "application/jsp", SvrType = JSV min 과 max 값의설정에주의한다. min 과 max 값은다음과같이설정되었다. HTH MinProc = 6 = 2 thread + 4 thread, HTH MaxProc = 25 = 10 thread + 15 thread 2.5. TCP 리스너사용 TCP 리스너는통신프로토콜을직접정의해서 TCP 클라이언트와 TCPServlet 간에통신할수있다. 단, TCP 리스너는 HTTP 또는 HTTPS 프로토콜로만족할수없는사항이있을경우에만사용하기를권장한다. TCP 리스너를사용하기위해서는다음과같은과정을수행해야한다. 1. 맞춤통신프로토콜을정의한다. 2. Dispatcher Config Class를구현한다 ( 프로토콜설정정보 ). 3. TCP 핸들러서블릿을구현한다 ( 프로토콜구현 ). 4. 맞춤프로토콜구현을위한 TCP 리스너를설정한다. 5. TCP 클라이언트를구현한다. 6. TCP 클라이언트를컴파일하고구동한다. 본절에서사용할용어는다음과같다. 용어 프로토콜 ( 통신프로토콜 ) 메시지 TCP 클라이언트 TCP 핸들러 설명 TCP 클라이언트와 TCP 핸들러사이에서 (TCP 리스너가중간역할 ) 교환되는메시지의구조와내용을정의한다. TCP 클라이언트와 TCP 핸들러사이에서교환되는데이터이다. 프로토콜에서정의한구조에맞아야한다. TCP 리스너와교신하며메시지를주고받는외부의애플리케이션 (TCP 핸들러에의해처리된다 ) 이다. 메시지를주고받는것은표준소켓을사용한다. TCP 리스너를통해메시지를받고구현된방법대로메시지를처리한다. TCP 핸들러는 jeus.servlet.tcp.tcpservlet의하위클래스의형태로구현되고웹엔진에보통서블릿처럼등록된다. TCP 핸들러는 TCP 프로토콜위에존재하는맞춤프로토콜의 " 제공자 " 또는 " 구현체 " 처럼동작한다고할수있다. 94 JEUS Web Engine 안내서

용어 TCP Dispatcher Configu ration Class 설명 TCP Dispatcher Configuration Class는 jeus.servlet.tcp.tcpdispatcherconfig 를확장한클래스이다. 이클래스는맞춤프로토콜에대한정보를 TCP 리스너로전달하여이 non-http 메시지를해석하여처리한다. 이클래스는 DOMAIN_HOME/lib/application 디렉터리아래에위치시키고, 웹엔진설정하위의 TCP 리스너설정항목중 'Dispatcher Config Class' 항목에설정한다 ( 2.3.4. TCP 리스너설정 참조 ). TCP 리스너 맞춤메시지에대한해석과라우팅인프라를제공한다. TCP 클라이언트와 TCP 핸들러사이에서 non-http 중간매개체로역할을한다. 이것은다른 HTTP 리스너와마찬가지로웹엔진내에존재한다. 2.5.1. 맞춤통신프로토콜정의 TCP 리스너는 TCP 클라이언트와 TCP 핸들러간에통신되는모든메시지들을두부분으로나누는데, 헤더와바디가그것이다. 일반적으로헤더는기본적이면서도표준정보를전달하고크기도정해져있다. 바디는전송될임의의사용자데이터가포함된다 ( 예 : HTTP 응답의 HTML 코드 ). TCP 리스너의사용을설명하기위해간단한프로토콜 ( 메시지구조 ) 을정의한다 ( 이것은나중에사용할것이다 ). 맞춤통신프로토콜 ( 맞춤메시지구조 ) 은다음과같은내용을가진다. 헤더 헤더는 4Bytes의 magic 수로시작한다. 이는사용되는프로토콜을식별한다. '7777' 로설정한다. 1Byte의 type 필드가 magic 수다음에쓰인다. '0' 은요청을 '1' 은응답을의미한다. 세번째항목은 4Bytes의 body length이다. 이항목은메시지의바디부분의 Byte 수를기록한다. 예제에서는크기가 128Bytes로고정되어있다. 마지막항목은 32Bytes의 string으로 service name을기록한다. 예제에서는그값으로요청을처리하는 TCPServlet의이름을입력한다. 바디메시지의바디부분은 128Bytes 길이를가진문자데이터를넣는다. 예제에서는이 128Byte 블록을 2 개의임의의 64Bytes 텍스트 string으로넣는다. 2.5.2. Dispatcher Config Class 구현 Dispatcher Config Class는 jeus.servlet.tcp.tcpdispatcherconfig Class의하위클래스이다. 이클래스의 abstract 메소드는 TCP 리스너가알맞은 TCP 핸들러에게메시지를전달하기위해필요한여러가지정보들이구현되어야한다. 이메소드들은 JEUS_HOME/docs/api/jeusapi/index.html에설명되어있다. 제 2 장웹커넥션관리 95

JEUS v7.0 Fix#1부터 getbodylengthlong 메소드가추가되었다. TCP Body의크기가 2GB 이상이라면해당메소드를사용해서 Body 길이를 8Byte로나타내면된다. 다음은정의된프로토콜에기반하여 Dispatcher Config Class를어떻게구현했는지를보여준다. 특정메소드들이어떻게사용되었는지는주석을참고한다. [ 예 2.4] TCPDispatcherConfig 구현예 : <<SampleConfig.java>> package sample.config; import javax.servlet.*; import javax.servlet.http.*; import jeus.servlet.tcp.*; /* This class extends the abstract class jeus.servlet.tcp. TCPDispatcherConfig class. This implementation provides routing and handling information to the TCP listener according to our defined communications protocol. */ public class SampleConfig extends TCPDispatcherConfig { /* Any init code goes into this method. This method will be Called once after starting the TCP listener. We leave this method empty for our simple example. */ public void init() {} /* This method returns the fixed-length of the header so that the TCP listener knows when to stop reading the header. The header length for our example is 41 (bytes): 4 (magic) + 1 (type) + 4 (body length) + 32 (service name). */ public int getheaderlength() { return 41; } /* This method must return the length of the body. For our example, this length is represented as an int in the header, starting at position 5 (see the protocol definition above). */ public int getbodylength(byte[] header) { return getint(header, 5); } 96 JEUS Web Engine 안내서

/**) * Returns the long-size length of request body of * incoming request packet. * If you don't need to support long, you may map to * {@link #getbodylength(byte[])}. */ public long getbodylengthlong(byte[] header) { return getbodylength(header); } /* This method must return the context path so that the request can be routed by the TCP listener to the context that contains the TCP handler (TCPServlet implementation). For our example, we always use the context path /tcptest. */ public String getcontextpath(byte[] header) { return "/tcptest"; } /* This method must return the name (path) of the TCP handler(tcpservlet) relative to the context path. For our example, we fetch this name from the 9th position in the header. */ public String getservletpath(byte[] header) { return "/" + getstring(header, 9, 32); } /* This method returns some path info from the header. It is not used in our example and thus returns null. */ public String getpathinfo(byte[] header) { return null; } /* This method returns any session ID embedded in the header. It is not used in our example and thus returns null. */ public String getsessionid(byte[] header) { return null; } 제 2 장웹커넥션관리 97

} /* This method determines whether the TCP listener should keep the socket connection open after the TCP handler has delivered its response. If it returns false, the connection will be dropped like in HTTP communications. If it returns true the connection will be kept open like in the Telnet or FTP protocols. For our example, we choose to make it persistent (connection not closed by the TCP listener). */ public boolean ispersistentconnection() { return true; } 2.5.3. TCP 핸들러구현 TCP 핸들러는항상 jeus.servlet.tcp.tcpservlet의하위클래스이다. 여기에는항상 overridden되는 abstract void service(tcpservletrequest req, TCPServletResponse res) 메소드가존재한다. 이서비스메소드는맞춤프로토콜에준하는메시지를처리할수있도록구현되어야한다. 메시지는 TCPServletRequest 객체에전달되고 TCP 핸들러로부터전달된응답은 TCPServletResponse 객체의 output stream으로출력된다. 다음예제는맞춤프로토콜에준하는메시지를처리하는 TCP 핸들러의구현코드이다. [ 예 2.5] TCPServlet 구현예 : <<SampleServlet.java>> package sample.servlet; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import jeus.servlet.tcp.*; /** * Sample TCPServlet implementation * * Protocol scheme: * * common header (for request and response) : total 41 byte * * magic field: length = 4 byte, value = 7777 * type field : length = 1 byte, 0 : request, 1:response * body length field : length = 4, value = 128 * service name field : length = 32 * 98 JEUS Web Engine 안내서

* request and response body * * message1 field : length = 64 * message2 field : length = 64 * */ public class SampleServlet extends TCPServlet { public void init(servletconfig config) throws ServletException { } public void service( TCPServletRequest req, TCPServletResponse res) throws ServletException, IOException { byte[] header = req.getheader(); byte[] body = req.getbody(); String encoding = res.getcharacterencoding(); if (encoding == null) encoding = "euc-kr"; DataInputStream in = new DataInputStream(new ByteArrayInputStream(header)); int magic = in.readint(); System.out.println("[SampleServlet] received magic = " + magic); byte type = (byte)in.read(); System.out.println("[SampleServlet] received type = " + type); int len = in.readint(); System.out.println("[SampleServlet] received body length = " + len); byte[] svcname = new byte[32]; in.readfully(svcname); System.out.println("[SampleServlet] received service name = " + (new String(svcname)).trim()); String rcvmsg = null; rcvmsg = (new String(body, 0, 64)).trim(); System.out.println("[SampleServlet] received msg1 = " + rcvmsg); //rcvmsg = (new String(body, 64)).trim(); try { rcvmsg = (new String(body, 64, 64, encoding)).trim(); } catch (Exception e) {} System.out.println("[SampleServlet] received msg2 = " + rcvmsg); 제 2 장웹커넥션관리 99

String msg1 = "test response"; String msg2 = "test response2"; byte[] result1 = null; byte[] result2 = null; if (encoding!= null) { try { result1 = msg1.getbytes(encoding); result2 = msg2.getbytes(encoding); } catch (UnsupportedEncodingException uee) { result1 = msg1.getbytes(); result2 = msg2.getbytes(); } } else { result1 = msg1.getbytes(); result2 = msg2.getbytes(); } header[4] = (byte)1; // mark as response ServletOutputStream out = res.getoutputstream(); out.write(header); byte[] buf1 = new byte[64]; System.arraycopy(result1, 0, buf1, 0, result1.length); out.write(buf1); byte[] buf2 = new byte[64]; System.arraycopy(result2, 0, buf2, 0, result2.length); out.write(buf2); } out.flush(); //out.close(); } public void destroy() { } 이는다소직설적인구현으로 TCPServletRequest 에서헤더와바디가꺼내어져오고 System.out 에헤더 와바디의각항목들이출력된다. 그후에 service() 메소드는 2 개의응답메시지를생성하고 TCPServle tresponse 객체의 output stream 에출력한다. 100 JEUS Web Engine 안내서

2.5.4. 맞춤프로토콜코드를위한 TCP 리스너설정 구현한코드 (SampleConfig.java와 SampleServlet.java) 를기반으로 TCP 리스너를설정한다. 설정과정은다음과같다. 1. 웹엔진에 TCP 리스너정보를설정한다. TCP 리스너정보설정에대한자세한내용은 2.3.4. TCP 리스너설정 을참고한다. 단, TCP 리스너에서참조하는서버리스너의포트는 '5555', 'Dispatcher Config Class' 는 'sample.con fig.sampleconfig' 를입력해야한다. 2. JEUS 서버를시작하고위에서작성한 TCPServlet을포함시킨웹애플리케이션을 deploy한다. 이때웹애플리케이션의 DD의예는다음과같다. [ 예 2.6] TCP 핸들러 DD : <<web.xml>> <?xml version="1.0" encoding="utf-8"?> <web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"> <display-name>test</display-name> <distributable/> <servlet> <servlet-name>sampleservlet</servlet-name> <servlet-class>sample.servlet.sampleservlet</servlet-class> <load-on-startup>0</load-on-startup> <async-supported>true</async-supported> </servlet> <servlet-mapping> <servlet-name>sampleservlet</servlet-name> <url-pattern>/sample</url-pattern> </servlet-mapping> <login-config> <auth-method>basic</auth-method> </login-config> </web-app> 2.5.5. TCP 클라이언트구현 TCP 클라이언트는 TCP 리스너와소켓연결을맺고이연결을통하여메시지를전송한다. 이메시지는 2.5.1. 맞춤통신프로토콜정의 에서정의한맞춤통신프로토콜에준하는 Byte 스트림이다. 설정된 TCP 리스너는메시지를받을것이고 SampleConfig 클래스에 dispatch 정보를물을것이다. 이정보는 SampleServlet 구현코드의 service() 메소드의호출을암시하고있다. SampleServlet은클라이언트로부터전달된데이터를출력하고응답을생성하여전송한다. 이응답은클라이언트가받아 System.out 으로출력한다. 제 2 장웹커넥션관리 101

다음은그에대한예이다. [ 예 2.7] TCP 클라이언트구현예 : <<Client.java>> package sample.client; import java.io.*; import java.net.*; public class Client { private String address; private int port; private int magic = 7777; private byte type = 0; private int bodylength = 128; private byte[] servicename="sample".getbytes(); public Client(String host, int port) { this.address = host; this.port = port; } public void test() throws IOException, UnsupportedEncodingException { Socket socket = new Socket(address, port); DataOutputStream out = new DataOutputStream( new BufferedOutputStream(socket.getOutputStream())); DataInputStream in = new DataInputStream( new BufferedInputStream(socket.getInputStream())); out.writeint(7777); out.write(type); out.writeint(bodylength); byte[] buf = new byte[32]; System.arraycopy(serviceName, 0, buf, 0, servicename.length); out.write(buf); byte[] msg1 = "test request".getbytes(); byte[] msg2 = "test request2".getbytes(); buf = new byte[64]; System.arraycopy(msg1, 0, buf, 0, msg1.length); out.write(buf); buf = new byte[64]; System.arraycopy(msg2, 0, buf, 0, msg2.length); out.write(buf); out.flush(); 102 JEUS Web Engine 안내서

// rx msg int magic = in.readint(); System.out.println("[Client] received magic = " + magic); byte type = (byte)in.read(); System.out.println("[Client] received type = " + type); int len = in.readint(); System.out.println("[Client] received body length = " + len); byte[] svcname = new byte[32]; in.readfully(svcname); System.out.println("[Client] received service name = " + (new String(svcname)).trim()); byte[] body = new byte[128]; in.readfully(body); String rcvmsg = null; rcvmsg = (new String(body, 0, 64)).trim(); System.out.println("[Client] received msg1 = " + rcvmsg); rcvmsg = (new String(body, 64, 64, "euc-kr")).trim(); System.out.println("[Client] received msg2 = " + rcvmsg); } out.close(); in.close(); socket.close(); } public static void main(string[] argv) throws Exception { Client client = new Client("localhost", 5555); client.test(); } 위의클라이언트코드에서프로토콜에필요한다양한헤더의필드들의설정을주의깊게확인한다. 'magic' 수는 '7777' 로, 'type' 은 '0'( 요청 ), 'body length' 는 '128Bytes'( 고정길이 ), 'service name' 은 'sample' 로설정되어있다 (SampleServlet의이름은 web.xml에설정되어있다 ). 그리고 2개의메시지들을생성하여헤더정보를전송한후에 TCP 리스너에게그들을전송한다. 마지막으로 'hostname' 을 'localhost' 로포트번호는 '5555' 로설정하였다. 2.5.6. TCP 클라이언트컴파일과실행 TCP 리스너가설정되어 'localhost' 에 '5555' 포트를이용하여운영되고있다고가정한다. 이런환경에서 TCP 클라이언트를컴파일하고실행하는과정은다음과같다. 제 2 장웹커넥션관리 103

1. Client.java 를컴파일한다. javac -classpath /usr/local/jeus/lib/system/jeus.jar-d. Client.java 2. Client.class 를다음과같이실행한다. java -classpath /usr/local/jeus/lib/system/jeus.jar:.sample.client.client 3. JEUS 관리자의콘솔윈도우는다음과같이 TCP 핸들러의결과값을보여줘야한다 (SampleServlet 클래스 ). [SampleServlet] received magic = 7777 [SampleServlet] received type = 0 [SampleServlet] received body length = 128 [SampleServlet] received service name = sample [SampleServlet] received msg1 = test request [SampleServlet] received msg2 = test request2 4. 다음의내용이클라이언트의실행화면에표시된다. [Client] received magic = 7777 [Client] received type = 1 [Client] received body length = 128 [Client] received service name = sample [Client] received msg1 = test response [Client] received msg2 = test response2 2.6. 커넥터제어 WebtoB 커넥터의경우 WebtoB를통해 JEUS로요청이들어오는데, 관리자가 WebtoB로부터요청을잠깐받고싶지않을경우가생길수있다. 이런경우 JEUS와 WebtoB 사이에약속된규칙에의하여 WebtoB 에게 JEUS로요청을보내지않도록제어할수있다. JEUS에서는다음과같은방법으로 WebtoB 커넥터를제어할수있다. WebAdmin을사용한제어 콘솔툴을사용한제어 WebAdmin 사용 다음은 WebAdmin을사용해서커넥터를제어하는방법이다. 1. WebAdmin에서서버에추가된웹커넥션들을조회하려면 [Servers] 메뉴를선택하여나타나는서버목록에서서버를선택하고 [Engine] > [Web Engine] > [Web Connection] 을클릭한다. 다음과같이서버에추가된웹커넥션목록이조회되고, 목록중제어가가능한웹커넥션인 'webtob' 타입의웹커넥션만 'Command' 컬럼의버튼이활성화된다. 104 JEUS Web Engine 안내서

[ 그림 2.41] 커넥터제어 - 웹커넥션조회 참고 'webtob' 타입외의다른타입의웹커넥션들에대한제어기능은제공하지않는다. 2. 제어가능한 WebtoB 커넥터는각각의커넥터에대하여 suspend와 resume 제어를할수있다. suspend 제어 [suspend] 버튼을클릭하면선택된 WebtoB 커넥터에 suspend 명령이내려지고, 이커넥터와연결된 WebtoB는선택된 JEUS로웹요청을보내지않는다. 다음은 WebtoB 커넥터 suspend 수행화면이다. [ 그림 2.42] 커넥터제어 - WebtoB 커넥터 suspend 수행 제 2 장웹커넥션관리 105

resume 제어 [suspend] 버튼을클릭하여웹요청이중지된 WebtoB 커텍터에 [resume] 버튼을클릭하면 WebtoB 는해당서버로웹요청을다시보내고, 서비스가정상적으로이루어진다. 다음은 WebtoB 커넥터 resume 수행화면이다. [ 그림 2.43] 커넥터제어 - WebtoB 커넥터 resume 수행 콘솔툴사용 다음은콘솔툴을사용해서커넥터를제어하는방법이다. suspend 제어콘솔툴에서서버에추가된 WebtoB 커넥터에대하여 suspend-web-component 명령을다음과같이수행하여요청을받지않도록한다. suspend-web-component -cn webtob1 resume 제어요청을받지않는 WebtoB 커넥터에대하여 resume-web-component 명령을다음과같이수행하여다시요청을받을수있도록한다. resume-web-component -cn webtob1 106 JEUS Web Engine 안내서

참고 suspend-web-component와 resume-web-component 명령에대한자세한내용은각각 JEUS Refer ence Book 의 4.2.8.37. suspend-web-component 와 JEUS Reference Book 의 4.2.8.32. resumeweb-component 를참고한다. 2.7. 리스너튜닝 최적의성능을위하여리스너를설정할때다음의몇가지사항을고려해야한다. 시스템리소스를많이사용하거나대기시간을길게하여출력버퍼의크기를증가시킨다. 일반적으로 Worker Thread Pool의 min, max, step 값을크게부여하면웹엔진에많은클라이언트가접근할때 Pool이좋은성능을가지게된다. 시스템메모리를적게사용하기위해서는이들의값을낮게설정한다. 'Server Access Control' 옵션을비활성화하면성능개선을기대할수있다. WebtoB 커넥터에서는앞에서언급했던공식에따라웹엔진의 Webtob 커넥터의 Worker Thread 개수와 http.m의값들을동일하게설정한다. 이렇게해야가장좋은성능을기대할수있다. 제 2 장웹커넥션관리 107

제 3 장웹컨텍스트 본장에서는 JEUS 웹애플리케이션을패키징하는방법과이를 JEUS 웹엔진에 deploy 하고모니터링하 는방법에대해설명한다. 3.1. 개요 웹애플리케이션을웹엔진에 deploy 하면웹컨텍스트가생성된다. 즉, 웹애플리케이션과웹컨텍스트는 동일한의미로봐도무방하므로두용어를혼용하지않고웹컨텍스트로통일해서사용할것이다. 3.2. 기본구조 본절에서는웹컨텍스트가포함하는내용과내부구조에대해서설명한다. 3.2.1. 웹컨텍스트콘텐츠 웹애플리케이션은클라이언트의요청에의한웹기반의서비스를수행하기위한정적콘텐츠와동적콘텐츠로구성되어있다. 정적콘텐츠사전에이미완성되어있는형태로웹엔진에서어떠한처리도하지않고반환하는모든종류의데이터들을의미한다. 정적콘텐츠의종류는다음과같다. HTML 페이지 텍스트파일 이미지파일 비디오 기타 동적콘텐츠서블릿, JSP와같이사용자의요청에따라응답을생성하는콘텐츠들을의미한다. 제 3 장웹컨텍스트 109

3.2.2. 웹컨텍스트내부구조 (WAR 파일구조 ) 웹컨텍스트는웹엔진에 deploy하기전에.war 확장자를가진 JAR 파일형식의압축파일로패키징해야한다. 이를 WAR(Web ARchive) 파일이라고한다. WAR 파일의구조는다음과같다. [ 그림 3.1] WAR 파일구조 WEB WAR T index.html static/ T.html jsp/ T.jsp images/ T.jps,.gif META-INF/ T MANIFEST.MF WEB-INF/ X X X X web.xml jeus-web-dd.xml ejb-jar.xml jeus-ejb-dd.xml classes/ C C Servlet.class EJB.class lib/ J Library JAR tlds/ T.tld META-INF/ 이디렉터리는선택사항이다. 있을경우에는 JAR 포맷에정의된 Descriptor 파일인 "MANIFEST.MF" 파일을포함한다. WEB-INF/ 이디렉터리는필수사항이고 Servlet, Filter, Listener 클래스들, 라이브러리들이포함되어있다. 이디렉터리하위에는다음과같은컴포넌트들이존재한다. 110 JEUS Web Engine 안내서

파일 web.xml 설명 Java EE 표준웹애플리케이션 DD 파일로웹애플리케이션의메타정보를가지고 있다. Servlet 3.0 부터는 web.xml 이반드시필요하지않다. 대신 Annotation, Registration API 를통해서 Servlet, Filter, Listener 들을추가할수있다. 자세한사항은 Servlet 표 준을참고한다. jeus-web-dd.xml ejb-jar.xml jeus-ejb-dd.xml classes/ JEUS의웹애플리케이션 DD로자세한설명은 3.3.1. jeus-web-dd.xml 설정 을참고한다. Java EE 6에포함된 EJB 3.1에서정의한 EJB in a.war에의해 WAR 파일에 EJB를포함할수있다. 이러한 DD이없어도 Servlet과마찬가지로 Annotation으로정의할수있다. 이에대한자세한설명은 EJB 표준또는 "JEUS EJB 안내서 " 를참고한다. Servlet 클래스들과유틸리티클래스들이하위디렉터리에포함되어있다. 표준 Java 패키지구조로정리되어있다. lib/ 웹애플리케이션에필요한 Java 라이브러리들을포함한다. 라이브러리들은.jar 파일들로패키지되어이경로에저장된다. 이파일들의내용들 은자동적으로모든 Servlet 의클래스경로에추가된다. tlds/ JSP 페이지들을위한 custom tag library descriptor 들을포함한다. 기타 JSP, HTML, 이미지파일들과같은콘텐츠를포함하고있는임의의이름의디렉터리이다. 3.3. 웹컨텍스트 Deploy 본절에서는웹컨텍스트의 Deploy에대해설명한다. Deploy는웹애플리케이션을 JEUS 웹엔진에서서비스할수있도록준비하여웹컨텍스트를생성하는과정이다. 웹컨텍스트는논리적으로가상호스트하위에존재한다. 가상호스트에대한더자세한사항은 제5장가상호스트 를참고한다. 3.3.1. jeus-web-dd.xml 설정 반드시필요한경우에한해 WEB-INF/ 디렉터리아래에 web.xml과 jeus-web-dd.xml을생성한다. 다음은 jeus-web-dd.xml 파일의예이다. 몇몇항목들은생략되어있다. 생략된항목들은 "JEUS XML Ref erence" 의 "13. jeus-web-dd.xml 설정 " 을참고한다. [ 예 3.1] 웹컨텍스트설정파일 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0"> <context-path>/examples</context-path> <enable-jsp>true</enable-jsp> 제 3 장웹컨텍스트 111

<auto-reload> <enable-reload>true</enable-reload> <check-on-demand>true</check-on-demand> </auto-reload> <added-classpath> <class-path>/home/user1/libs/lib.jar</class-path> </added-classpath> <session-config>... </session-config> <async-config> <async-timeout-millis>600000</async-timeout-millis> <background-thread-pool> <min>0</min> <max>10</max> </background-thread-pool> <dispatch-thread-pool> <min>0</min> <max>10</max> </dispatch-thread-pool> </async-config> <properties> <property> <key>jeus.servlet.jsp.modern</key> <value>true</value> </property> </properties> </jeus-web-dd> 다음은설정태그에대한설명이다. 태그 <context-path> <enable-jsp> <user-log> <auto-reload> <added-classpath> 설명웹컨텍스트에접근하기위한 Root Path이다. 이것은반드시 '/' 로시작해야하며가상호스트내에서유일해야한다. http://www.foo.com/examples/index.html과같은 URL에서 <context path> 는 "/examples" 가된다. false로설정했을때 JSP 기능을사용하지않는다. 기본적으로 JSP를지원한다. 웹컨텍스트가남기는로그이다. 유저로그에대한자세한내용은절 1.6.10. 유저로그설정 을참고한다. 디스크의 Servlet 클래스가변경되었을때자동적으로로딩할지여부를결정하는옵션이다. 자세한내용은 제8장클래스동적반영 을참고한다. Servlet을실행할때참조할라이브러리들의리스트이다. 디렉터리도설정가능하다. 112 JEUS Web Engine 안내서

태그 <allow-indexing> 설명클라이언트가요청했을때실제디렉터리목록이출력되는 URL 경로의목록이다. 클라이언트에서요청한파일이디렉터리에없을경우에디렉터리의목록이출력된다. 대신에디렉터리목록의파일을하나선택하면해당파일의내용이출력된다. <deny-download> 어떤경우에라도직접적으로다운로드받거나접근할수없는자원들을규정하기 위한필터이다. 이필터들은파일이름의확장자로파일이름과함께경로로지정 할수있다. 필터의파일이름과디렉터리들은 context document base 디렉터리의상대적인 경로로설정된다. <aliasing> Custom URL 경로에대한디렉터리매핑을의미한다. 다른위치의디렉터리를 URL 요청경로에매핑시킬필요가있는경우에 aliasing 기능을사용한다. <file-caching> 응답속도향상을위해런타임메모리에어떤정적콘텐츠를 Cache 해야할지결 정한다. 이항목의하위설정들은 Cache 메모리의최대크기 ( 단위 : MB), 요청되지않을때 Cache 내에머무를수있는정적콘텐츠의최대크기, Caching 되어야할콘텐츠 의경로가있다. <jsp-engine> <session-config> 웹컨텍스트에포함된 JSP 페이지에대한설정이다. 자세한내용은 4.4.2. jeusweb-dd.xml 설정 을참고한다. 웹컨텍스트레벨의세션을설정한다. 이설정은웹엔진에설정한것보다우선순위가높다. 세션설정에대한자세한내 용은 1.6.9. 세션설정 을참고한다. <webinf-first> <attach-stacktraceon-error> <keep-alive-errorresponse-codes> 클래스로딩우선순위에관한옵션으로 true로설정하면해당애플리케이션에한해서 WEB-INF 하위의클래스를우선적으로로딩한다. 서버에문제가발생했을때오류의상세내역을브라우저로보여줄것인지에대한설정이다. 이메시지는개발하는경우에는유용하지만운영하는경우에는제거하는것이좋다. 에러응답코드중에서 Connection: Close 대신 Keep-Alive 응답을주길원하는값을설정한다. 웹애플리케이션이직접에러응답을내보낼때적용되며, 엔진내부적으로커넥션을끊어야할필요가있다고판단한경우에는적용되지않는다. 예를들어서블릿이 response.senderror(500) 을수행한경우에는적용되지만서 블릿에서 exception 이발생해서엔진이 500 에러를보내는경우에는적용되지않 는다. 여러개의응답코드를설정하려면 "404,503" 과같이콤마 (,) 로구분한다. <encoding> Request, Response 에대한인코딩설정이다. 웹엔진설정 (domain.xml) 과동일하 지만동시에설정될경우 jeus-web-dd.xml 의설정이우선적용된다. 자세한내용 은 1.6.5. 인코딩설정 을참고한다. 제 3 장웹컨텍스트 113

태그 설명 Request encoding : HTTP 요청의질의문, 쿠키및 postdata Block을위한인코딩 Response encoding : 웹엔진으로부터받은전체응답 HTTP 메시지에적용되는인코딩 <cookie-policy> <async-config> <web-security> <properties> HTTP Request Header에있는쿠키를읽거나애플리케이션요청에의해새로운쿠키를 HTTP Response Header를사용할때적용하는정책을설정할수있다. 자세한내용은 1.6.8. 쿠키정책설정 을참고한다. Servlet 3.0부터추가된 Async Processing에관한설정이다. 하위에는 Async Timeout, Background Thread Pool, Dispatch Thread Pool에대한설정을할수있다. Async Processing에관한자세한내용은 Servlet 표준을참고한다. sendredirect할경우에주소값검증에대한정책설정등웹애플리케이션에국한된보안정책들의설정그룹이다. 웹애플리케이션에적용되는프로퍼티를설정한다. 여기에설정된프로퍼티는다른웹애플리케이션에는적용되지않고, 설정된웹애플리케이션에만적용된다. 참고 <async-config><async-timeout-millis> 의기본값은 30초이다. 만약 Background Thread에서수행하는작업이너무오래걸리는경우가있어서타임아웃에러가발생한다면 jeus-web-dd.xml에이값을설정하거나 javax.servlet.asynccontext#settimeout() 으로프로그램에서조절한다. 3.3.2. 웹컨텍스트 Redeploy(Graceful Redeploy) 웹컨텍스트의 Redeploy 에대한내용은본안내서에서는생략한다. 자세한내용은 JEUS Applications & Deployment 안내서 의 2.2. Graceful Redeployment 를참고한다. 3.3.3. Shared Library Reference 추가 공유라이브러리 (Shared Library) 는애플리케이션별로필요한라이브러리를 WEB-INF/lib가아닌 JEUS_HOME/lib/shared 아래에추가한후에여러애플리케이션에서공유하여사용할수있다. JEUS의재기동없이도 libraries.xml 파일수정후모듈을다시 deploy하면변경된라이브러리가반영된다. 공유라이브러리를추가하려면다음과같이 JEUS_HOME/lib/shared/libraries.xml 파일에서 <library> 태그를추가하고공유할 JAR 파일들을지정한다. 버전은스펙버전과구현체버전을각각지정할수있다. [ 예 3.2] Shared Library Reference 추가 : <<libraries.xml>> <libraries xmlns="http://www.tmaxsoft.com/xml/ns/jeus"> <!-- DO NOT MODIFY JSF1.2 and JSTL1.2 libraries!!! --> 114 JEUS Web Engine 안내서

<library> <library-name>jsf</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2_06</implementation-version> <files dir="."> <include name="jsf-injection-provider.jar"/> </files> <files dir="jsf_ri_1.2"/> </library> <library> <library-name>jsf</library-name> <specification-version>2.0</specification-version> <implementation-version>2.0.0</implementation-version> <files dir="."> <include name="jsf-injection-provider.jar"/> <include name="jsf-weld-integration.jar"/> </files> <files dir="jsf_ri_2.0"/> </library> <library> <library-name>jstl</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2</implementation-version> <files dir="jstl_1.2"/> </library> <!-- Add user libraries from here --> <library> <library-name>mylibrary</library-name> <specification-version>2.0</specification-version> <implementation-version>2.1</implementation-version> <files dir="."> <include name="commons-logging.jar"/> <include name="commons-util.jar"/> </files> <files dir="mylib-2.1"/> </library> </libraries> 설정한공유라이브러리를참조하려면 jeus-web-dd.xml에다음과같이 <library-ref> 를설정한다. 버전이명시되지않은경우는 libraries.xml에등록된동일한이름의라이브러리중에서최상위버전을참조한다. <library-ref> <library-name>mylibrary</library-name> <specification-version>2.0</specification-version> </library-ref> 제 3 장웹컨텍스트 115

JSF, JSTL 라이브러리설정 [ 예 3.2] 에설명한 libraries.xml 파일에는 JSF와 JSTL이공유라이브러리로추가되어있다. Java EE 표준은 JSF와 JSTL을포함하고있기때문에 JEUS에서기본적으로제공한다. JEUS 시스템라이브러리로제공할수도있지만하나의 JSF, JSTL 구현체만사용할수있는제약사항이발생한다. JSF 구현체는 2.0뿐만아니라 1.2 버전도있고 Sun RI가아닌 Apache의 MyFaces도있기때문에 JEUS에서는여러가지버전의구현체를사용할수있도록공유라이브러리형태로 JSF, JSTL을제공한다. 구현체의위치와종류에따라사용되는구현체는다음과같이구분된다. WEB-INF/lib 아래에 JSF나 JSTL 구현체가있을경우에는이들구현체가우선사용된다. WEB-INF/lib 아래에 JSF나 JSTL 구현체가없을경우에는 lib/shared 아래의 JSF, JSTL가사용된다. 2 가지라이브러리의경우 jeus-web-dd.xml에 <library-ref> 설정이없어도사용할수있다. 특정버전의 JSF나 JSTL을사용하려면 libraries.xml에 <library> 를등록하고 jeus-web-dd.xml에서 <libraryref> 로참조하도록설정한다. JSF의경우 Managed Bean에서 @EJB나 @Resource와같은 Annotation으로 WAS가제공하는리소스에접근할수있고 WAS는 Annotation으로명시된리소스들을 injection할수있어야한다. JEUS에서는 JSF RI에 JEUS Injection을지원하기위해서공유라이브러리로 jsf-injection-provider.jar를제공하고있다. 공유라이브러리는다음의디렉터리에존재한다. JEUS_HOME/lib/shared 3.3.4. 호환성을위한웹컨텍스트레벨의옵션설정 이전 JEUS 버전이나타 WAS와호환성에문제가발생한경우에웹컨텍스트레벨에서옵션을설정하여해결할수있다. 이전 JEUS 와의호환성 Servlet 2.4 표준이전에는표준자체에제약사항이제대로기술되지않은경우가많았다. 이는 Servlet 2.4, 2.5를거치면서보완되었고 JEUS에서도자연스럽게제약사항이생기게되었다. 또한 JEUS도여러가지문제점을경험하고이를수정하면서표준을따르지않는동작들을지원하지않게되었다. 이에따라 JEUS 4에서작성한웹애플리케이션이 JEUS 6에서제대로동작하지않는문제들이발생할수있다. JEUS는 Servlet 및 JSP 표준을준수해야할책임이있지만기존애플리케이션의동작호환성을보장해야할책임도있다. 하지만이두가지책임은서로상충하는면이있다. 주로표준준수를위해서 javax.servlet 표준 API, 내부동작을수정했을때, 기존의잘못된동작에기반하여작성한애플리케이션이있을때문제가발생한다. 이런상황에서는기본적으로표준준수요구사항이우선순위가더높기때문에해당애플리케이션을수정해야할필요가있다. 왜냐하면그애플리케이션을다른웹컨테이너에서는실행할수없기때문이다. 또한시간이지남에따라애플리케이션을업그레이드하는과정에서 Servlet 표준을준수하는 Framework들과도충돌하는문제가발생할수있다. 116 JEUS Web Engine 안내서

하지만이러한애플리케이션의문제점을초기에파악하지못하고서비스개시일을앞두고발견한경우애플리케이션의수정대신 JEUS의동작을수정하는요구사항이발생한다. 이를지원하기위해서 JEUS 에서는하위호환성을위한프로퍼티를제공한다. JSP 엔진에관한호환성문제는 4.4.3. JSP 하위호환성을위한웹컨텍스트레벨의옵션설정 을참고하고, 하위호환성을위해 JEUS에서제공하는프로퍼티에대한자세한내용은 JEUS Reference Book 의 1.6.3.3. 호환성제공프로퍼티 를참고한다. 다른 WAS 와의호환성 Servlet 2.4 표준이전에는 Servlet과 JSP를직접사용해서웹애플리케이션을개발했지만현재는 Web Framework를사용하는추세이고, Java EE 5부터는표준 Web Framework로 JSF와 JSTL이추가되었다. 이러한 Web Framework는주로 Servlet, JSP 스펙에대한참조구현체인 Tomcat을사용해서개발하고테스트하기때문에 Web Framework들이비표준적인기능을지원할경우에다양한호환성관련문제가발생할수있다. 호환성에문제가발생했을때필요한경우에한해서 jeus-web-dd.xml에설정할수있다. jeus-web-dd.xml 의설정에대한자세한내용은 JEUS Reference Book 의 1.6. 웹엔진프로퍼티 를참고한다. 3.3.5. 부가기능사용을위한설정 JEUS에서제공하는다음의부가기능을사용하려면별도의설정이필요하다. 정적리소스를처리하는서블릿매핑 Spring 3.0 이상에서 mvc:default-servlet-handler 등록방법 정적리소스를처리하는서블릿매핑 Servlet 표준에서는 Servlet 또는 JSP가아닌경우 WAS에서제공하는 Default Servlet으로처리하도록되어있다. 이를 ResourceServlet이라고한다. 다음과같이 web.xml에서 <servlet-mapping> 설정에 jeus.servlet.servlets.resourceservlet으로매핑하면된다. [ 예 3.3] 정적리소스를처리하는서블릿매핑 : <<web.xml>> <servlet-mapping> <servlet-name>jeus.servlet.servlets.resourceservlet</servlet-name> <url-pattern>/static/*</url-pattern> </servlet-mapping> 제 3 장웹컨텍스트 117

Spring 3.0 이상에서 mvc:default-servlet-handler 등록방법 Spring 3.0 이상에서 mvc:default-servlet-handler를등록하는방법은다음과같다. 1. web.xml에다음과같이등록한다. [ 예 3.4] mvc:default-servlet-handler를위한 ResourceServlet 등록 : <<web.xml>> <servlet> <servlet-name>jeus.servlet.servlets.resourceservlet</servlet-name> <servlet-class>jeus.servlet.servlets.resourceservlet</servlet-class> </servlet> 2. Spring에서사용하는설정파일에다음과같이등록한다. [ 예 3.5] mvc:default-servlet-handler 설정 <beans> <mvc:default-servlet-handler default-servlet-name="jeus.servlet.servlets.resourceservlet"/> </beans> 3.3.6. 웹보안설정 jeus-web-dd.xml 을통해애플리케이션별로적용할웹보안설정에대해설명한다. Redirect Location 보안설정 애플리케이션은 javax.servlet.http.httpservletresponse.sendredirect(string location) 표준 API를통해서 "302 Found" 응답을보낼수있다. 이때기본적으로 Location으로넘겨주는문자열에대해서아무런확인을하지않고그대로 URL로전환해서 Location 헤더로설정한다. 그렇기때문에악의적인사용자가 CRLF injection과같은공격을할수있다. 이를방지하기위해애플리케이션은 jeus.servlet.security.redirectstrat egy 인터페이스를구현해서 jeus-web-dd.xml에설정할수있다. 다음은 jeus.servlet.security.redirectstrategy 인터페이스를설정한예이다. [ 예 3.6] Redirect Location 보안설정인터페이스 : <<RedirectStrategy>> package jeus.servlet.security; import javax.servlet.http.httpservletrequest; public interface RedirectStrategy { /** * Makes the redirect URL. * * @param location the target URL to redirect to, for example "/login" 118 JEUS Web Engine 안내서

} */ String makeredirecturl(httpservletrequest request, String location) throws IllegalArgumentException; 설정한인터페이스를다음과같이구현할수있다. [ 예 3.7] Redirect Location 보안설정구현예 : <<RejectCrlfRedirectStrategy>> package jeus.servlet.security; import javax.servlet.http.httpservletrequest; public class RejectCrlfRedirectStrategy implements RedirectStrategy { private Pattern CR_OR_LF = Pattern.compile("\\r \\n"); @Override String String makeredirecturl(httpservletrequest request, String location) throws IllegalArgumentException { if (CR_OR_LF.matcher(location).find()) { throw new IllegalArgumentException("invalid characters (CR/LF) in redirect location"); } return makeabsolute(location); } } private String makeabsolute(string location) { } // make code for make absolute path jeus-web-dd.xml의설정방법은다음과같다. [ 예 3.8] Redirect Location 보안설정 : <<jeus-web-dd.xml>>... <web-security> <redirect-strategy-ref> jeus.servlet.security.rejectcrlfredirectstrategy </redirect-strategy-ref> </web-security>.. <redirect-strategy-ref> 는 jeus.servlet.security.redirectstrategy 인터페이스를구현한클래스이름이다. 이클래스는웹애플리케이션의클래스패스에포함시키면된다. 위에서제시한 jeus.servlet.security.rejectcrlfredirectstrategy의경우기본적으로제공하는 RedirectStrat egy이며 CR, LF 또는 CRLF가있는 Location이 sendredirect API로넘어올경우 500 에러가발생한다. 제 3 장웹컨텍스트 119

그외에도 CR, LF 또는 CRLF 문자열을빈문자열로치환해주는 jeus.servlet.security.removecrlfredirect Strategy 를제공한다. 3.3.7. 보안 Role 매핑 본절에서는 web.xml에정의된보안 Role을실제시스템사용자와사용자그룹에설정하는방법에대해설명한다. 이매핑은 jeus-web-dd.xml에기술된다다음의내용을 web.xml에정의했다고가정한다. [ 예 3.9] 보안 Role 매핑 : <<web.xml>> <web-app> <security-role> <role-name>manager</role-name> </security-role> <security-role> <role-name>developer</role-name> </security-role> <servlet>... </servlet> <security-constraint> <web-resource-collection> <web-resource-name> MyResource </web-resource-name> <url-pattern>/jsp/*</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection> <auth-constraint> <role-name>manager</role-name> </auth-constraint> </security-constraint> </web-app> 위의예제에서는 2 개의보안 Role 이선언되어있다 ( 굵은글씨로표현된부분 ). 세번째굵은글씨로표현 된부분은 manager role 이 <security-constraint> 태그에어떻게사용되는지나타낸다. 이매핑을 jeus-web-dd.xml에기술하면다음과같다. [ 예 3.10] 보안 Role 매핑 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0">... <role-mapping> 120 JEUS Web Engine 안내서

<role-permission> <principal>peter</principal> <role>manager</role> </role-permission> <role-permission> <principal>linda</principal> <role>developer</role> </role-permission> </role-mapping>... </jeus-web-dd> 웹애플리케이션이실제의시스템에 deploy될때 "manager" 와 "developer" Role을시스템의특정한사용자로바인딩해야한다. 이매핑은 <context><role-mapping> 에정의되어있다. <role-mapping> 태그는 <role-permission> 태그를포함한다. 이태그를이용하여 <principal-to-role> 매핑을정의한다. 다음의하위태그들과함께바인딩된다. 태그 <role>(1 개, 필수 ) <principal>(0 개이상 ) 설명 web.xml에정의된 <role-name> 값이며, 위의예에서는 <role-name> 이 "manag er" 이다. <role-name> 과연계되어야할 JEUS가관리하는사용자의이름이다. 자세한내용은 JEUS Security 안내서 의 3.3. 웹모듈보안설정 을참고한다. 2 개의 Role "manager" 와 "developer" 가 "Peter" 와 "Linda" 로각각매핑되어있다. 3.3.8. Symbolic Reference 매핑 Role이실제사용자에매핑되듯이 EJB Reference, Resource Reference, 관리되는객체의 Reference를실제시스템자원에매핑할필요가있다. 다음은 Symbolc Reference 매핑의예이다. [ 예 3.11] Symbolc Reference 매핑 : <<web.xml>> <web-app>... <ejb-ref> <ejb-ref-name>ejb/account</ejb-ref-name> <ejb-ref-type>entity</ejb-ref-type> <home>com.mycompany.accounthome</home> <remote>com.mycompany.account</remote> </ejb-ref> <resource-ref> 제 3 장웹컨텍스트 121

<res-ref-name>jdbc/employeeappdb</res-ref-name> <res-type>javax.sql.datasource</res-type> <res-auth>container</res-auth> <res-sharing-scope>shareable</res-sharing-scope> </resource-ref> <resource-env-ref> <resource-env-ref-name> jms/stockqueue </resource-env-ref-name> <resource-env-ref-type> javax.jms.queue </resource-env-ref-type> </resource-env-ref>... </web-app> 이웹애플리케이션을등록하기위해 web.xml의 <ejb-ref>, <resource-ref>, <resource-env-ref> 아래의모든 Symbolc Reference 이름들이실제의도하는자원의 JNDI 이름과매핑되어야한다. 이매핑은 jeusweb-dd.xml에서해당 <ejb-ref>, <res-ref>, <res-env-ref> 를추가하면완성된다. 이태그들은다음의하위태그들을포함한다. <jndi-info> 태그 <ref-name> <export-name> 설명 Reference 의이름으로 web.xml 과 Servlet 코드에정의된것과같은것이다. JNDI Export Name 은 <ref-name> 이가리키는실제리소스의 Export Name 이다. 다음은 JNDI 이름이위의 3개의 Reference와매핑된 jeus-web-dd.xml의예이다. [ 예 3.12] Symbolc Reference 매핑 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0">... <ejb-ref> <jndi-info> <ref-name>ejb/account</ref-name> <export-name>accountejb</export-name> </jndi-info> </ejb-ref> <res-ref> <jndi-info> <ref-name>jdbc/employeeappdb</ref-name> <export-name>employeedb</export-name> </jndi-info> </res-ref> 122 JEUS Web Engine 안내서

<res-env-ref> <jndi-info> <ref-name>jms/stockqueue</ref-name> <export-name>stockqueue</export-name> </jndi-info> </res-env-ref>... </jeus-web-dd> 3.4. 웹컨텍스트모니터링 모니터링은웹컨텍스트의정보를확인하는것이다. 웹엔진에배치되어있는웹컨텍스트의목록및현재 상태등을 WebAdmin 이나콘솔툴을사용하여조회할수있다. WebAdmin 사용 WebAdmin을사용하여 deploy된웹컨텍스트를조회할수있다. 조회방법은다음과같다. 1. WebAdmin의 [Applications] 메뉴를선택하면다음과같이도메인내의애플리케이션목록이조회된다. 목록에서 'Application Type' 이 'WAR' 인애플리케이션의 ID를클릭한다 ( 웹애플리케이션의타입은 WAR이다 ). [ 그림 3.2] 웹컨텍스트모니터링 - 애플리케이션조회 제 3 장웹컨텍스트 123

2. 모니터링을원하는웹애플리케이션의 ID를클릭하면다음과같이해당웹애플리케이션의정보가조회된다. 해당웹애플리케이션의 ID, 경로, 타입등의기본정보와 Target 관련정보, Option 관련정보가조회된다. [ 그림 3.3] 웹컨텍스트모니터링 - 웹애플리케이션선택 화면에대한자세한설명은 JEUS Applications & Deployment 안내서 의 4.3.10. 애플리케이션정보확인 을참고한다. 3. 조회화면의 'Running Servers' 에서조회된서버중원하는서버를클릭하면선택한서버의세부정보화면이새로운탭으로나타난다. 124 JEUS Web Engine 안내서

[ 그림 3.4] 웹컨텍스트모니터링 - 웹애플리케이션세부정보조회 화면의각영역에대한설명은다음과같다. General information of web module 선택된웹애플리케이션의모듈이름, 컨텍스트이름, 컨텍스트경로의정보가조회된다. Servlets 선택된웹애플리케이션에등록된서블릿에대한정보가조회된다. 각각의서블릿에대해 web.xml이나 Annotation 또는프로그램 API를통해등록된형식과매핑된 URL 패턴, 클래스이름과현재서블릿의상태, Anync/Sync 여부등의정보가조회된다. Filters 제 3 장웹컨텍스트 125

선택된웹애플리케이션에등록된필터에대한정보가조회된다. 각각의필터에대해 web.xml이나 Annotation 또는프로그램 API를통해등록된형식과매핑된 URL 패턴, 클래스이름등이조회된다. Listeners 선택된웹애플리케이션에등록된리스너의등록방식과리스너종류가조회된다. EJBs 선택된웹애플리케이션에등록된 EJB의 Bean Name, Type, Local Export Name, Remote Export Name 의정보가조회된다. 콘솔툴사용 콘솔툴을사용하여웹컨텍스트를모니터링할수있다. deploy된웹컨텍스트를조회하려면다음과같이 application-info 명령을수행한다. 웹컨텍스트의모든정보가조회된다. application-info 명령에대한자세한내용은 JEUS Reference Book 의 4.2.6.3. applicationinfo 를참고한다. application-info -type WAR 특정웹컨텍스트의정보를조회하려면다음과같이 -id <application-id> 옵션을설정하여명령을수행한 다. 해당 ID 의웹컨텍스트정보가조회된다. application-info -id <application-id> 3.5. 웹컨텍스트제어 웹컨텍스트를제어한다는것은웹컨텍스트의상태를변경하여서비스를변경하는것을의미한다. WebAdmin이나콘솔툴을사용하여웹컨텍스트를리로드하거나중지및재개하는등의제어가가능하다. 3.5.1. 웹컨텍스트리로드 배치되어있는웹컨텍스트가변경이있거나특별한이유로다시초기화해야할필요가있을경우에웹컨텍스트를제거한후다시배치하지않고, 변경사항을반영하여웹컨텍스트를리로드한다. WebAdmin과콘솔툴을사용하여웹컨텍스트를리로드할수있다. WebAdmin 사용 WebAdmin 을사용한웹컨텍스트리로드방법은다음과같다. 126 JEUS Web Engine 안내서

1. [Applications] 메뉴를선택하면조회되는애플리케이션목록에서웹애플리케이션의 ID를클릭한다. 조회화면의 'Running Servers' 목록에서조회할서버를클릭한다. 2. 해당서버이름의탭이추가되고, 해당웹컨텍스트의 [reload] 버튼을클릭하면화면상단에리로드의결과가표시된다. [ 그림 3.5] 웹애플리케이션 reload 콘솔툴사용 콘솔툴을사용하여웹컨텍스트를리로드할수있다. 다음과같이 reload-web-context 명령을수행한다. reload-web-context 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.23. reload-web-context 를참고한다. reload-web-context -ctx <context-name> seccessfully reloaded 제 3 장웹컨텍스트 127

3.5.2. 웹컨텍스트의비동기요청에대한 Thread Pool 모니터링 웹컨텍스트가비동기요청 (Asynchronous Request) 을처리할때 JEUS가제공하는 Thread Pool을사용하려면 jeus-web-dd.xml의 <async-config> 에관련정보를설정해야한다. <async-config> 를설정한후에 JEUS에서제공하는 Async Thread Pool 정보를모니터링할수있다. 다음은 jeus-web-dd.xml의설정예이다. [ 예 3.13] <async-config> 설정 : <<jeus-web-dd.xml>>... <async-config> <dispatch-thread-pool> <min>5</min> <max>20</max> </dispatch-thread-pool> <background-thread-pool> <min>5</min> <max>20</max> </background-thread-pool> <async-timeout-millis>120000</async-timeout-millis> </async-config>... 다음은설정태그에대한설명이다. 태그 <dispatch-thread-pool> <background-threadpool> <async-timeout-millis> 설명 AsyncContext#dispatch를호출할때사용할 Thread Pool의최소 Thread값과최대 Thread값을설정한다. AsyncContext#start를호출할때사용할 Thread Pool의최소 Thread값과최대 Thread값을설정한다. Asynchronous 작업을수행할때웹컨테이너가 Timeout을처리하는데기준이되는시간을설정한다. 애플리케이션이 AsyncContext#setTimeout을호출하지않은경우 AsyncContext#getTimeout일때설정된값을리턴한다. ( 기본값 : 30000, 단위 : ms) 설정된정보에따른 Async Thread Pool 정보는 WebAdmin 을통해확인할수있다. 128 JEUS Web Engine 안내서

WebAdmin 사용 WebAdmin을사용한웹컨텍스트의 Thread 정보조회방법은다음과같다. 1. [Applications] 메뉴를선택하면조회되는애플리케이션목록에서웹애플리케이션의 ID를클릭한다. 조회화면의 'Running Servers' 목록에서조회할서버를클릭한다. 2. 해당서버이름의탭이추가되고, 해당웹컨텍스트의 [thread-info] 버튼을클릭하면 thread-info 정보화면이새로운탭으로나타난다 [ 그림 3.6] 웹애플리케이션 thread-info 제 3 장웹컨텍스트 129

3.5.3. 웹컨텍스트중지 배치되어서비스되고있는웹컨텍스트를관리자가특정시간이나특별한사유로웹엔진내의특정웹컨텍스트의서비스를잠깐중지할수있다. 중지된웹컨텍스를다시리로드할수도있다. 웹컨텍스트리로드방법에대한자세한내용은 3.5.4. 웹컨텍스트리로드 를참고한다. WebAdmin 사용 WebAdmin 을사용한웹컨텍스트의중지방법은 JEUS Applications & Deployment 안내서 의 4.3.7. 애 플리케이션중지 를참고한다. 콘솔툴사용 콘솔툴을사용하여웹컨텍스트를중지할수있다. 다음과같이 suspend-web-component 명령을수행한다. suspend-web-component 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.37. suspend-web-component 를참고한다. suspend-web-component -ctx <context> 3.5.4. 웹컨텍스트리로드 중지되어있는웹컨텍스트를다시재개할수있다. WebAdmin 과콘솔툴을사용하여웹컨텍스트를리로드할수있다. WebAdmin 사용 WebAdmin 을사용하여중지된웹컨텍스트를시작하는방법은 JEUS Applications & Deployment 안내 서 의 4.3.6. 애플리케이션시작 을참고한다. 콘솔툴사용 콘솔툴을사용하여중지된웹컨텍스트를재개할수있다. 다음과같이 resume-web-component 명령을수행한다. resume-web-component 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.32. resume-web-component 를참고한다. resume-web-component -ctx <context> 130 JEUS Web Engine 안내서

3.6. 웹컨텍스트튜닝 최고의성능을위해웹컨텍스트의설정 (jeus-web-dd.xml) 을튜닝할때다음과같은사항들을고려해야한다. 유저로그는버퍼의크기를증가시키고 "stdout" 의사용을자제한다. JSP 엔진은사용하지않으면 OFF시킨다. <enable-reload> 와 <check-on-demand> 옵션은항상 OFF시킨다. 이옵션은클래스변경이잦은개발환경에서만사용한다. 가능하면파일 Caching 기능을사용한다. 최대한많은양의정적콘텐츠디렉터리를파일 Caching 태그에설정한다. Cache의 <max-idle-time> 과 <max-cache-memory> 의값을크게설정한다 ( 무한대로설정해도무방하다 ). 3.7. 비동기식처리프로그래밍가이드 본절에서는 Servlet 3.0 부터추가된비동기식처리 (Asynchronous Processing) 에관해서애플리케이션개 발자가반드시숙지해야할내용에대해설명한다. 3.7.1. Servlet 표준에따른주의사항 애플리케이션개발자가직접 Thread를다뤄야하는비동기식처리프로그래밍의특성으로인해다음과같은실수가발생할수있다. Thread의과다생성 Thread를과도하게많이생성해서 JVM의성능을떨어뜨리거나 OutOfMemoryError 상태에빠진다. 서로다른 Thread 간에공유하면안되는객체의공유서로다른 Thread 간에공유하면안되는객체를함께사용한다. 비동기식으로처리하는 Thread에서 javax.servlet.requestdispatcher 사용비동기식으로처리하는 Thread에서 javax.servlet.requestdispatcher를사용한다. 이중에는테스트할때는발견하지못하다가실제서비스중에부하가많이발생했을때나타나는문제들이있다. 이는 JEUS에서보장할수없는문제들로전적으로애플리케이션개발자에게책임이있음을명심하기바란다. 참고 본절에서설명하는내용은 Servlet 표준을기반으로작성한것이다 (JEUS 에만해당하는것이아니 다 ). 제 3 장웹컨텍스트 131

Thread 의과다생성 Thread를과도하게많이생성하면 JVM의성능이떨어지거나 OutOfMemoryError 상태에빠진다. 다음은 Thread를과도하게많이생성한잘못된비동기식처리프로그램밍의작성예이다. [ 예 3.14] 잘못된비동기식처리프로그래밍작성예 (1) import javax.servlet.asynccontext; import javax.servlet.servletexception; import javax.servlet.annotation.webservlet; import javax.servlet.http.httpservlet; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; import java.io.ioexception; @WebServlet(urlPatterns = "/WrongAsyncServlet1", asyncsupported = true) public class WrongAsyncServlet1 extends HttpServlet { @Override protected void doget(httpservletrequest req, HttpServletResponse resp) throws ServletException, IOException { AsyncContext asynccontext = req.startasync(); Thread thread = new Thread(new TestRunnable(asyncContext)); thread.start(); } private class TestRunnable implements Runnable { private final AsyncContext asynccontext; public TestRunnable(AsyncContext asynccontext) { } this.asynccontext = asynccontext; } } @Override public void run() { } 비동기식처리가필요한요청은서비스상황에따라서동시에수천개가될수도있다. 그때마다새로운 Thread를생성하면동시에수천개의 Thread가존재하게된다. 이로인해서 JVM의성능이심각하게저하되거나 "OutOfMemoryError: unable to create new native thread" 와같은에러가발생할수있다. 따라서가능하면 javax.servlet.asynccontext#start(runnable) 메소드를사용하거나직접관리하는 Thread Pool을사용할것을권장한다. AsyncContext asynccontext = req.startasync(); asynccontext.start(new TestRunnable(asyncContext)); 132 JEUS Web Engine 안내서

서로다른 Thread 간에공유하면안되는객체의공유 서로다른 Thread 간에공유하면안되는멀티스레드에안전하지않은객체를함께사용하면성능저하, 교착상태또는데이터의무결성을침해할수있다. 다음은서로다른 Thread 간에공유하면안되는객체를공유한잘못된비동기식처리프로그램밍의작성예이다. [ 예 3.15] 잘못된비동기식처리프로그래밍작성예 (2) import javax.servlet.asynccontext; import javax.servlet.servletexception; import javax.servlet.servletinputstream; import javax.servlet.servletoutputstream; import javax.servlet.annotation.webservlet; import javax.servlet.http.httpservlet; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; import java.io.ioexception; @WebServlet(urlPatterns = "/WrongAsyncServlet2", asyncsupported = true) public class WrongAsyncServlet2 extends HttpServlet { @Override protected void doget(httpservletrequest req, HttpServletResponse resp) 해 throws ServletException, IOException { AsyncContext asynccontext = req.startasync(); asynccontext.start(new TestRunnable(asyncContext)); 밍 byte[] buffer = new byte[1024]; ServletInputStream inputstream = req.getinputstream(); inputstream.read(buffer); } ServletOutputStream outputstream = resp.getoutputstream(); outputstream.write(buffer); private class TestRunnable implements Runnable { private final AsyncContext asynccontext; public TestRunnable(AsyncContext asynccontext) { } this.asynccontext = asynccontext; @Override public void run() { byte[] buffer = new byte[1024]; try { ServletInputStream inputstream = asynccontext.getrequest(). 제 3 장웹컨텍스트 133

getinputstream(); inputstream.read(buffer); } catch (IOException e) { //log error return; } } } } ServletOutputStream outputstream; try { outputstream = asynccontext.getresponse().getoutputstream(); outputstream.write(buffer); } catch (IOException e) { //log error return; } 위의예제는 Request 객체로부터얻을수있는 ServletInputStream이나 Reader 객체또는 Response 객체로부터얻을수있는 ServletOutputStream이나 Writer 객체를서로다른 Thread에서함께사용하는경우이다. Servlet 표준에의거하여 JEUS는이러한동작에대해안정성을보장하지않는다. 필터또는서블릿에서비동기식처리를시작해서다른 Thread로동작을넘겼다면그이후필터및서블릿코드에서는가능하면모든동작을비동기식처리를수행하는 Thread 측에맡겨야한다. 이는멀티스레드프로그래밍에대한잘못된이해로인한성능저하, 교착상태 (Dead Lock) 나데이터무결성침해를피하는방법이기도하다. startasync() 로직접호출하지않은필터또는서블릿에서비동기식처리가시작됐는지확인하려면 javax.servlet.servletrequest#isasyncstarted() 를체크한다. 비동기식으로처리하는 Thread 에서 javax.servlet.requestdispatcher 사용 비동기식으로처리하는 Thread에서 javax.servlet.requestdispatcher를사용하면원하는데로프로그램이동작하지않거나 Exception이발생할수있다. 다음은 Thread에서 javax.servlet.requestdispatcher를사용한잘못된비동기식처리프로그램밍의작성예이다. [ 예 3.16] 잘못된비동기식처리프로그래밍작성예 (3) import javax.servlet.asynccontext; import javax.servlet.requestdispatcher; import javax.servlet.servletexception; import javax.servlet.annotation.webservlet; import javax.servlet.http.httpservlet; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; 134 JEUS Web Engine 안내서

import java.io.ioexception; @WebServlet(urlPatterns = "/WrongAsyncServlet3", asyncsupported = true) public class WrongAsyncServlet3 extends HttpServlet { @Override protected void doget(httpservletrequest req, HttpServletResponse resp) throws ServletException, IOException { AsyncContext asynccontext = req.startasync(); asynccontext.start(new TestRunnable(asyncContext)); } private class TestRunnable implements Runnable { private final AsyncContext asynccontext; public TestRunnable(AsyncContext asynccontext) { } this.asynccontext = asynccontext; @Override public void run() { //... do something RequestDispatcher requestdispatcher = asynccontext.getrequest().getrequestdispatcher("/views/report.jsp"); try { requestdispatcher.forward(asynccontext.getrequest(), asynccontext. getresponse()); } catch (ServletException e) { // log error } catch (IOException e) { // log error } } } } 비동기식처리를진행하는 Thread 에서다른서블릿이나 JSP 로 dispatch 하기위한방법은 javax.servlet.asynccontext 에서제공하고있다. asynccontext.dispatch("/views/report.jsp"); 제 3 장웹컨텍스트 135

3.7.2. 기타주의사항 비동기식처리프로그래밍에대해표준에서설명하고있는주의사항외에도주의해야할사항이존재한다. AsyncContext.start(Runnable) 를호출했을때 Thread에서 java.util.concur rent.rejectedexecutionexception이발생하는경우 AsyncContext.start는새로운태스크 (Task) 를나타낸다. 이태스크를수행하기위해서는 Thread가필요한데, 일반적으로 Thread는제한된리소스이기때문에 Thread Pool을사용한다. 새로운태스크를 Thread Pool에할당했을때해당태스크를수행할수있는 Thread가하나도없다면큐에쌓이게된다. 일반적으로오랜수행시간을필요로하는태스크의경우에 Thread의처리가지연되면태스크들은큐에적채된다. 큐역시사이즈 ( 기본값 ( 최댓값 ): 4096) 가제한되어있으므로결국에는새로운태스크를할당할수없는상태가된다. 이러한상황에도달하면 java.util.concurrent.rejectedexecutionexception이발생한다. 그러므로애플리케이션프로그래머는이러한상태를고려해서비동기식처리를프로그래밍해야한다. 136 JEUS Web Engine 안내서

제 4 장 JSP 엔진 본장에서는 JSP 엔진의개념과기능, 설정방법에대해설명한다. 4.1. 개요 JSP 엔진은웹엔진에내부적으로포함되어있는형태이며웹컨텍스트마다하나씩존재한다. 본장에서는 JSP 표준에대한설명은포함하지않는다. JSP 작성등에대한자세한정보는 JSP 표준을참고한다. JSP 엔진은웹클라이언트가 JSP 페이지를요청했을때해당페이지를찾아서 Servlet으로전환하는역할을한다. Servlet 으로전환하는과정에서 Java 파일과 SMAP 파일을생성하고, Java 파일을컴파일해서서비스에이용할클래스파일을생성한다. JSP 프리컴파일기능을사용하지않았다면 JSP 컴파일은최초요청시점에수행한다. 따라서최초요청의경우에는 OS 파일시스템에접근하는일이빈번하게발생하기때문에응답시간이늦을수있다. NAS(Network Attached Storage) 를사용하는환경에서태그와 JSP include 관계때문에컴파일해야할파일이많은경우에는 NAS로많은요청이집중되서응답시간이지체되는현상이발생할수있다. 또한 NAS 드라이버동작에따라 java.io.ioexception이발생하지않고사이즈가 0인 JSP 파일을읽는경우도발생한다. Jasper에서는 JVM File I/O API를통해서파일을읽기때문에이런경우 JSP 파일에대한파싱이실패할수밖에없다. [ 경고 ] 내부테스트결과 Oracle JDK 6에서제공하는 javac 라이브러리가 thread-safe하지않다. 이에따라 jeus.servlet.jsp.compile-java-source-concurrently 프로퍼티를제공하며, 기본값은 false이다. 그래서요청스레드가.java 파일을컴파일할때는 JVM Scope의 Lock을잡고수행한다. 만약 JDK에서제공하는 javac 라이브러리가 thread-safe한경우에는다음과같이 jeus-web-dd.xml에 true 로설정해서사용해도될것이다. 단, 반드시단일스레드가아닌멀티스레드상황에서 JSP 컴파일이정상적으로되는지테스트해야한다. <properties> <property> <key>jeus.servlet.jsp.compile-java-source-concurrently</key> <value>true</value> </property> </properties> 제 4 장 JSP 엔진 137

4.2. Apache Tomcat Jasper JEUS는기존부터 Tomcat의 JSP Parser인 Japser를도입해서사용했으나패키지이름을변경하고이를 jeus.jar에포함하여제공하였다. JEUS 7부터는 org.apache.jasper 패키지의이름를그대로유지하고별도의 jasper.jar 라이브러리로패키징하여제공한다. 이라이브러리는다음경로에위치한다. $JEUS_HOME/lib/system/jasper.jar Jasper를사용할때는다음의사항에주의한다. jasper.jar는일부 JEUS에맞춰서수정한것이므로 Tomcat의것으로덮어쓰면안된다. 이경우서버기동이실패한다. 웹애플리케이션에서 WEB-INF/lib 내에 Tomcat의 jasper.jar를사용하는경우 jeus-web-dd.xml의 <webinffirst> 옵션을 true로설정해야한다. 그렇지않으면 JEUS에서사용하는 jasper.jar의클래스를사용하게되어기대하는동작과다를수있다. Tomcat Jasper 와 JEUS Jasper 의차이점 위에서언급한바와같이 JEUS는 Tomcat에서제공하는 Japser를일부수정해서제공한다. 그러므로사용할때다음의사항을고려해야한다. JEUS는 In-memory JSP Compiliation 기능과같이 Tomcat Jasper에서제공하지않는기능을제공한다. JEUS에서는 Tag Handler Pool, PageContext Pool을사용하지않는다. Eclipse JDT 컴파일러제공 위에서언급한바와같이 JEUS는기본적으로 Eclipse JDT 컴파일러를사용하지않지만다음과같이 jeusweb-dd.xml 설정으로사용할수있다. <jsp-engine> <java-compiler>eclipse</java-compiler> </jsp-engine> Eclipse JDT 컴파일러의라이브러리는다음경로에위치한다. $JEUS_HOME/lib/system/ecj.jar 경고 Eclipse JDT 컴파일러는 JDK에서정식으로사용하는라이브러리가아니므로안정성을보장할수없다. Tomcat Jasper와의호환성을고려해서연결고리만제공하는것이므로이를감안해서사용한다. 138 JEUS Web Engine 안내서

Java 소스컴파일시 64KB 메소드크기제한문제 JSP를작성할때하나의.jsp 파일내에내용이너무많은경우이를.java 파일로생성하면내부메소드크기가 64KB를초과할수있다. 이경우해당.java 파일은 Java Languague 표준규약을어긴것이므로 Java 컴파일러로컴파일되지않는다. 그러나.jsp의내용중 SQL 문이나 HTML 태그와같은문자열이대부분을차지하는경우에는 64KB 제한을피해갈수있다. 애플리케이션이가지고있는 web.xml에다음과같이설정한다. <servlet> <servlet-name>jeus.servlet.servlets.jspservlet</servlet-name> <servlet-class>jeus.servlet.servlets.jspservlet</servlet-class> <init-param> <param-name>genstraschararray</param-name> <param-value>true</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>jeus.servlet.servlets.jspservlet</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping> 문자열이아니라실제로 Java 코드량이많은경우에는컴파일에실패할수밖에없다. 이때는 <jsp:include> 를사용하여응답내용을분리해서구현한다. 다음은 <jsp:include> 를사용한예이다. <body> Template Page<br/> <jsp:include page="module_one.jsp" /> <jsp:include page="module_two.jsp" /> </body> 4.3. JSP 엔진의기능 JSP 엔진은리로딩, 프리컴파일, Graceful Reloading, 메모리에서의 JSP 컴파일및실행기능등을제공 한다. 4.3.1. JSP 리로딩 JSP 파일은사용목적이비즈니스로직보다는사용자뷰에가깝기때문에실제서비스운영중에도수정할수있기를원하는경우가대부분이다. 이런이유로 JSP를많이사용하는웹애플리케션의경우 WAR 형태보다는디렉터리형태로 deploy한다. 디렉터리형태로 deploy한경우디렉터리로 deploy한상태에서해당디렉터리아래의 JSP 파일을수정하면 JSP 엔진에서기존에컴파일된클래스파일의마지막수정시각과원본 JSP 파일의수정시각을비교해서컴파일을수행한다. 제 4 장 JSP 엔진 139

이때 <check-included-jspfile> 설정이 true인경우에는요청한 JSP 파일이변경되지않았더라도, 해당 JSP 파일이 include한 JSP 파일들이나 TAG 파일들 (.tld) 을체크해서 JSP 파일을재컴파일한다. WAR 형태로 deploy한경우 WAR 형태로 deploy할경우 WAR 파일전체를리패키징해서 redeploy를해야하기때문에서비스운영측면에서리스크가큰편이다. 하지만변경하는 JSP 파일이많은경우에는 JEUS 7부터제공하는 Graceful Redeploy를고려할수있다. Graceful Redeploy에관한자세한사항은 3.3.2. 웹컨텍스트 Redeploy(Graceful Redeploy) 를참고한다. 웹컨텍스트내에서의 JSP JSP 파일은웹컨텍스트의루트아래에존재한다. 별도로디렉터리를생성해서패키징할수도있고 Servlet 3.0부터정의한 META-INF/resources/ 디렉터리아래에패키징할수도있다. WEB-INF/lib/ 아래의 *.jar 라이브러리파일들안에 META-INF/resources/ 디렉터리가있는경우에도 JSP 파일을찾을수있다. 단, WEB-INF/ 디렉터리아래에있는 JSP 파일은서비스되지않는다. 웹클라이언트가 WEB-INF/ 아래의파일들에보안상접근할수없다. 웹컨텍스트내부구조에대한자세한내용은 3.2.2. 웹컨텍스트내부구조 (WAR 파일구조 ) 를참고한다. 참고 META-INF/resources/ 에대한자세한내용은 http://docs.oracle.com/javaee/6/api/javax/servlet/servlet Context.html 의리소스관련 API 설명을참고한다. 4.3.2. JSP 프리컴파일 JSP 프리컴파일은웹컨텍스트의 JSP 페이지들을미리컴파일할수있는기능이다. 이는 appcompiler 스크립트나콘솔툴의 precompile-jsp( 약어 jspc) 명령을통해서가능하다. appcompiler는오프라인상태에서도 JSP 프리컴파일이가능하고, precompile-jsp는 JEUS에 deploy된모듈에대해서프리컴파일을수행할수있다. 이기능을사용하면 JSP가처음요청되었을때의성능을향상시킬수있다. appcompiler나콘솔툴의 precompile-jsp 명령에대한자세한내용은각각 JEUS Reference Book 의 4.3. appcompiler 와 JEUS Reference Book 의 4.2.8.22. precompile-jsp 를참고한다. 4.3.3. JSP Graceful Reloading 기능 NAS를사용하거나웹애플리케이션이 Remote 장비에 exploded 모드로 deploy하여여러개의웹엔진이이를공유해서하나의소스로동일한서비스를수행하는경우부하상황에서 Hang이발생할가능성이있다. 부하상황에서 JSP 소스가수정되거나 touch를통해 JSP의시간이변경된시점에웹엔진으로들어온요청에의해서 JSP 컴파일이수행된다. 공유된 JSP 파일로여러웹엔진 ( 다른 JVM) 으로부터컴파일이 140 JEUS Web Engine 안내서

수행되면서해당파일에대한경쟁 (contention) 이발생하는경우가있다. 이로인해서비스가느려지거나 Hang이걸린것과같은현상이발생한다. JSP Graceful Reloading 기능은공유된 JSP 파일에대한 exclusive한컴파일을가능하게하기위해도입되었다. 해당 JSP 파일에대한 FILELOCK을이용하여경쟁하지않고하나의웹엔진만이컴파일수행을보장받는다. Reloading Thread가엔진마다생성되며이 Thread가주기적으로 Reloading 작업을수행하게된다. JSP Graceful Reloading 기능의설정방법은 4.4.1. 웹엔진레벨에서의설정 을참고한다. 참고 JSP Graceful Reloading 기능을사용하면 Reloading을위한추가 Thread 생성, 주기적인 FILELOCK, 모니터링의부하현상이발생한다. 그러므로 NAS에 JSP 소스를공유하는구조에서서비스의 Hang 발생상황을회피하는용도로사용할것을권장한다. 4.3.4. 메모리에서의 JSP 컴파일및실행기능 NAS를사용해서여러개의웹엔진이이를공유해서하나의소스로동일한서비스를수행하는경우 JSP 컴파일시점에필요한 OS 파일시스템접근작업으로인해서비스지연현상또는에러가발생할수있다. 이러한문제점을해결하기위해서 JSP 프리컴파일, JSP Graceful Reloading 기능을제공하지만이를좀더근본적으로해결하기위해서메모리에서의 JSP 컴파일및실행기능을제공한다. JSP 엔진은요청처리스레드에서 JSP 컴파일의결과물인.java 파일및.class 파일을저장하지않고모두메모리에두고사용한다. 따라서.jsp 파일의메타데이터와.jsp 파일의콘텐츠를읽는작업이외에는파일시스템에접근하지않는다. 이렇게파일시스템접근을최소화하여 JSP 컴파일타임에발생할수있는서비스지연을최소화하였다. 그러나.java 파일및.class 파일은추후다른용도를위해서필요하다. 이파일들은요청처리스레드가아닌 JSP 엔진마다하나씩가지고있는 Background Thread를이용해서파일시스템에사용한다. 순차적으로처리하기때문에파일 I/O가파일시스템에한번에몰릴확률이낮다. 하지만.smap 파일은사용하지않는다. 만약.smap 파일이필요한경우에는기존의 JSP 컴파일방식을사용해야한다. JSP 엔진은이기능을기본적으로사용한다. 만약기존과같은방식을원하는경우에는 jeus-web-dd.xml 에설정할수있다. 자세한설정사항은 4.4.2. jeus-web-dd.xml 설정 을참고한다. 제 4 장 JSP 엔진 141

4.4. JSP 엔진설정 JSP 엔진은 WebAdmin 을사용하거나각웹애플리케이션의 jeus-web-dd.xml 에설정할수있다. 4.4.1. 웹엔진레벨에서의설정 웹엔진의 JSP 엔진설정은 WebAdmin을통해서해야한다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Jsp Engine] 메뉴를선택한다. [ 그림 4.1] JSP 엔진설정 - 메뉴이동 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 142 JEUS Web Engine 안내서

3. Jsp Engine 화면에서기본정보를설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 4.2] JSP 엔진설정 - 기본정보설정 제 4 장 JSP 엔진 143

설정항목에대한설명은다음과같다. Jsp Work Dir JSP 에서생성된 Java 소스파일들이저장되는루트디렉터리를지정한다. 참고루트디렉터리에바로파일을생성하는것은아니다. JSP 엔진이속한도메인, 서버이름, 그리고웹애플리케이션이름으로디렉터리를생성한후그아래에파일을생성한다. 즉, 서로다른웹엔진간에클래스파일들을공유하지않는다. 'Compile Output Dir' 항목을설정하지않은경우클래스파일도동일한위치에생성된다. 기본적으로다음과같은위치에생성된다. EAR 애플리케이션 INTERNALGENERATED_HOME/ear1/web1/ jsp_work Standalone 웹모듈 INTERNALGENERATED_HOME/web1/ jsp_work Java Compiler Java Compiler 실행명령어이다. JSP의생성된 Java 소스를 Servlet 클래스로컴파일하기위한컴파일러를지정한다. 기본설정이가장효율적이기때문에사용하지않는것을권장한다. Compile Output Dir JSP Parser가생성한 Java 파일을컴파일한클래스파일의위치이다. 이클래스파일을실제로서비스에사용한다. 설정하지않는경우 Java 파일과동일한위치에생성된다. Compile Option Java 컴파일러실행옵션이다. Compile Encoding JSP Parser가생성한 Java 파일의인코딩을지정한다. Check Included Jspfile JSP 엔진은기본적으로요청한 JSP 페이지의변경여부만검사해서컴파일한다. 만약 true로설정하면요청한 JSP 페이지뿐만아니라 <%@ include file= xxx.jsp %> directive로 include 된모든 JSP 파일들및태그파일들에대해변경되었는지확인해서컴파일한다. Keep Generated JSP Parser가생성한 Java 파일및 SMAP 파일을유지하는옵션이다. 디버깅할때유용하고, false로설정하면파일을생성한후삭제하는것이기때문에특별한이유가없다면성능을위해별도의설정을하지않는것을권장한다. Graceful Jsp Reloading 144 JEUS Web Engine 안내서

JSP 파일이여러웹엔진에서공유되고있을경우하나의웹엔진에서일괄적으로 JSP 파일을 Java 파일로변환하고, 이파일들을컴파일하도록지정할수있다. 이때나머지웹엔진들은메모리에있는기존컴파일된파일로서비스가된다. 기능에대한자세한설명은 4.3.3. JSP Graceful Reloading 기능 을참고한다. 'Jsp Work Dir' 항목의설정에의해여러웹엔진이같은폴더를공유할경우 Graceful Jsp Reloading 을사용하려면 true로설정한다. Graceful Jsp Reloading Period Graceful Jsp Reloading 동작을위해 JSP 파일변경을체크하는주기를설정한다. Use In Memory Compilation 서비스중인 JSP 파일을새로컴파일해야할때.java 및.class 파일을메모리에생성해서컴파일하고이를실행하는기능이다. 자세한사항은 4.3.4. 메모리에서의 JSP 컴파일및실행기능 을참고한다. 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭하면다음과같은결과메시지를확인할수있다. [ 그림 4.3] JSP 엔진설정 - 설정적용결과 4.4.2. jeus-web-dd.xml 설정 JSP 엔진설정은 jeus-web-dd.xml에서도가능하다. [ 예 4.1] 웹컨텍스트설정파일 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0"> <enable-jsp>true</enable-jsp> <jsp-engine> <jsp-work-dir>/home/user1/myjspwork/</jsp-work-dir> <!--compile-output-dir>/home/user1/myjspwork/</compile-output-dir--> 제 4 장 JSP 엔진 145

<java-compiler>java6</java-compiler> <compile-option>-g:none verbose</compile-option> <compile-encoding>utf-8</compile-encoding> <check-included-jspfile>true</check-included-jspfile> <keep-generated>true</keep-generated> <graceful-jsp-reloading>true</graceful-jsp-reloading> <graceful-jsp-reloading-period>35000</graceful-jsp-reloading-period> <use-in-memory-compilation>true</use-in-memory-compilation> </jsp-engine> </jeus-web-dd> 다음은설정태그에대한설명이다. 태그 <enable-jsp> <jsp-engine> 설명 false로설정하면 JSP 기능을사용하지않는다. 기본적으로 JSP를지원한다. 웹컨텍스트에포함된 JSP 페이지에대한설정이다. 이 element는 WebAdmin의 JSP 엔진설정과동일하다. 만약 jeus-web-dd.xml 파일에 JSP 엔진이설정되어있다면, 여기에설정된내용이 domain.xml에설정된것보다우선한다. WebAdmin 에서의 JSP 엔진설정에대한자세한내용은 4.4.1. 웹엔진레벨에서 의설정 을참고한다. 4.4.3. JSP 하위호환성을위한웹컨텍스트레벨의옵션설정 JEUS 4 및 5에서는사용자의편의성과 Servlet 2.3 이전에개발된애플리케이션을위해서표준이아닌기능도제공하고, JSP 문법체크도최신스펙에비해서엄격하지않게적용하였다. 하지만 JEUS 6부터는좀더엄격한문법체크와 JSP 2.1 기능을제대로지원하기위해 Jasper 기반의 JSP Parser로교체하였다. 하지만기존 JSP에대한하위호환성을위해서기존의 JSP Parser도지원한다. 따라서 JEUS 4 및 5에서는문제가없던웹모듈을 deploy하면여러가지에러가발생할수있다. JSP 2.1 등의최신스펙을사용하려면 JSP 컴파일할때발생하는에러메시지를확인후수정해서업그레이드해야한다. deploy할때다음과같은형태로에러가발생한다면 /jsp/customtag12/date.jsp의 2번째라인의 62번째컬럼에서어떤문제가있는지확인해야한다. [2007.01.15 10:02:29][2][b029] [mycontainer-12] [WEB-5697] [examples#examples] par sing 35 jsp file(s) [2007.01.15 10:02:33][1][b029] [mycontainer-12] fail to parse jsp file : /jsp/cust omtag12/date.jsp << Exception >> jeus.servlet.jsp2.jsp2engineexception: file:/jeus6/webhome/johan_mycontainer/examples/examples_war /jsp/customtag12/d ate.jsp(2,62) Failed to load or instantiate TagExtraInfo class: customtag12.showdatetei at jeus.servlet.jsp2.compiler.defaulterrorhandler.jsperror(defaulterrorhandler 146 JEUS Web Engine 안내서

.java:59) at jeus.servlet.jsp2.compiler.errordispatcher.dispatch(errordispatcher.java:467) at jeus.servlet.jsp2.compiler.errordispatcher.jsperror(errordispatcher.java:298) 만약최신스펙이필요하지않고기존에개발된모듈을그대로사용하려면다음과같이 jeus-web-dd.xml 에 JEUS 4 및 5 호환의 JSP Parser가해당웹컨텍스트에만적용되도록설정할수있다. [ 예 4.2] JSP 하위호환성을위한웹컨텍스트설정 : <<jeus-web-dd.xml>> <properties> <property> <key>jeus.servlet.jsp.modern</key> <value>false</value> </property> </properties> jeus-web-dd.xml에설정한옵션은해당웹컨텍스트에만적용되고, 웹엔진이나가상호스트단위로도옵션을설정할수있다. 웹엔진레벨에서옵션을적용하려면다음과같은 VM 옵션을설정한다. VM 옵션의설정은 JEUS Server 안내서 의 2.2. 서버추가 를참고한다. -Djeus.servlet.jsp.modern=false VM 옵션은가상호스트, 웹컨텍스트레벨에서치환이가능하며 jeus-web-dd.xml에설정한옵션이최종적으로적용된다. jeus-web-dd.xml에옵션설정이없다면상위의기본설정이적용된다. 이옵션은하위호환성이필요한경우만적용하고, 신규개발은새로운애플리케이션으로표준을준수하여개발할것을권장한다. 참고 나머지옵션에대한자세한내용은 JEUS Reference Book 의 1.6. 웹엔진프로퍼티 를참고한다. 제 4 장 JSP 엔진 147

제 5 장가상호스트 본장에서는가상호스트의사용목적, 규칙및설정방법등에대해설명한다. 5.1. 개요 가상호스트는인터넷도메인이름을기준으로같은 URL로서로다른웹애플리케이션에매핑할수있도록한다. 즉, 2개이상의도메인이름 ( 예. www1.foo.com and www2.foo.com ) 을하나의웹엔진에설정하여서로다른웹컨텍스트를서비스할수있다. 참고 웹엔진관점에서웹컨텍스트는웹애플리케이션과동일한의미이다. 5.2. 웹엔진과가상호스트 본절에서는가상호스트의사용목적, 규칙, ServletContext 객체와가상호스트의관계에대해설명한다. 사용목적 가상호스트에매핑된도메인이름을기준으로, 같은 URL로서로다른웹애플리케이션에매핑할수있다. 따라서서비스제공자는하나의웹엔진으로 2개이상의웹사이트를서비스이용자에게제공할수있다. 이는 HTTP 1.1의 Host 헤더를이용해서가상호스트를제공하는기능과동일하다. 가상호스트는웹엔진에설정할수있는일종의웹컨텍스트그룹이다. 가상호스트가웹엔진의구성요소로서어떻게위치하는지는 [ 그림 1.1] 을참고한다. 다음은가상호스트의사용목적에따른이용패턴을보여준다. 제 5 장가상호스트 149

[ 그림 5.1] 가상호스트의이용패턴 위의예제를보면, 서로다른 2개의주소로서로같은컨텍스트패스 (/service) 에접근할수있다. 실제로는하나의서버뿐이지만 HTTP 클라이언트입장에서는 "www.foo.com" 과 "www.bar.com" 이라는 2대의서버가존재하는것처럼인식된다. 서비스제공자입장에서는 "/service" 라는동일한주소패턴으로서로다른서비스를제공할수있다. 위의예제에서는 "www.foo.com" 은한국어서비스를, "www.bar.com" 은영어서비스를제공하고있다. 규칙 가상호스트를구성할때적용되는규칙은다음과같다. 가상호스트에는가상호스트이름을부여한다. 가상호스트의이름은설정파일내에서가상호스트를참조하기위해서내부적으로사용되는이름으로웹엔진내에서유일해야한다. 하나의가상호스트는 1개이상의도메인이름이나 IP 주소를매핑할수있다. JEUS는이를호스트이름이라고한다. 서로다른가상호스트에같은호스트이름을매핑할수없다는점에유의한다. 동일한이름의웹컨텍스트는서로다른가상호스트에 deploy할수없다. 경고 Servlet 표준에서서로다른가상호스트에서동일한웹컨텍스트를공유할수없다고정의되어있다. 동일한패스를가진서로다른웹컨텍스트를각각서로다른가상호스트에 deploy할수있다. 단, 하나의가상호스트내에서는동일한패스를가진 2개이상의웹컨텍스트는존재할수없다. 웹컨텍스트이름은 Java EE 표준에서정의한애플리케이션또는모듈이름을의미한다. 패스는웹애플리케이션내에서정의하는 Context Root 또는 Context Path를의미한다. 웹컨텍스트이름은 JEUS Deploy 차원에서관리하는것이며, 웹엔진은 Context Path를관리한다. 150 JEUS Web Engine 안내서

JEUS 웹엔진에는기본가상호스트 (Default Virtual Host) 라는묵시적인가상호스트가존재한다. 웹컨텍 스트를 deploy 할때명시적으로가상호스트에지정하지않으면, 기본가상호스트로 deploy 한다. 이가상 호스트의이름은 "DEFAULT_HOME" 이다. 예약어이므로다른가상호스트이름으로지정할수없다. 5.2.1. ServletContext 객체와가상호스트 Servlet API에는 javax.servlet.servletcontext.getcontext(string contextpath) 라는메소드가있다. "con textpath" 에의해주어진 ServletContext 객체를리턴한다. 이메소드는 ServletContext가속하는가상호스트에존재하는 ServletContext를리턴한다. 만약해당가상호스트내에없으면기본가상호스트에서찾는다. 5.3. 가상호스트를통한웹컨텍스트요청 본절에서는 URL과가상호스트내에존재하는웹컨텍스트를매칭하는방법에대해설명한다. 다음은웹엔진과가상호스트, 웹컨텍스트간의유효한관계의예시를나타낸다. [ 그림 5.2] 웹엔진과가상호스트, 웹컨텍스트간의유효한관계의예 Web Engine Context ctx1 path=/ctx1 Virtual Host A www.foo.com Context ctx2 path=/ctx2 Virtual Host B www.bar.com Context ctx1-1 path=/ctx1 Virtual Host C www.bar2.com www.foo2.com Context ctx2-2 path=/ctx2 5.3.1. URL 매칭예제 [ 그림 5.2] 를기반으로각각의 URL 이매칭되는가상호스트와웹컨텍스트는다음과같다. http://www.foo.com/ctx1/test.jsp 매칭되는가상호스트 매칭되는웹컨텍스트이름 A ctx1 제 5 장가상호스트 151

http://www.foo.com/ctx2/test.jsp 매칭되는가상호스트 매칭되는웹컨텍스트이름 A ctx2 http://www.bar.com/ctx1/ 매칭되는가상호스트 매칭되는웹컨텍스트이름 B ctx1-1 http://www.bar2.com/ctx1/test.jsp 매칭되는가상호스트 매칭되는웹컨텍스트이름 C 없음 (404 Not Found) http://www.foo2.com/ctx2/ 매칭되는가상호스트 매칭되는웹컨텍스트이름 C ctx2-2 경고 웹컨텍스트이름과컨텍스트패스는서로다른개념이다. 일반적으로같은값을사용하지만지금처 럼가상호스트를이용해서서비스를구분하는경우에는서로달라진다. 5.3.2. URL 매칭순서 URL이매칭되는순서는다음과같다. 1. Host 헤더의도메인이름을등록된모든가상호스트에매칭시킨다. 매칭된가상호스트가있다면그안에서웹컨텍스트를찾는다. 2. 웹컨텍스트가발견되지않았으면기본가상호스트에서찾는다. 3. 기본가상호스트에서원하는웹컨텍스트가없으면 "404 Not Found" 에러가발생한다. 152 JEUS Web Engine 안내서

5.4. 가상호스트설정 WebAdmin 과콘솔툴을사용하여가상호스트를추가, 수정및삭제할수있다. 참고 본절의설정예제에서는편의상이름을 "A", "B", "C" 로사용하였다. 실제환경에서는의미있는이름 을사용한다. 5.4.1. 추가 WebAdmin 과콘솔툴을사용하여가상호스트를추가할수있다. WebAdmin 사용 WebAdmin을사용하여가상호스트를추가하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Virtual Host] 메뉴를선택한다. [ 그림 5.3] 가상호스트추가 - 메뉴이동 2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 제 5 장가상호스트 153

3. 가상호스트추가를위해 [ADD] 버튼을클릭하여다음과같이각항목을설정하고, [ 확인 ] 버튼을클릭한다. 'Virtual Host Name' 으로 'A', 'B', 'C' 를차례로설정한다. 다음은 'C' 라는이름의가상호스트를설정한화면이다. [ 그림 5.4] 가상호스트추가 - 기본정보설정 항목 Virtual Host Name Host Name Properties 설명가상호스트를참조하기위해내부적으로사용하는이름이다. "DEFAULT_HOST" 는기본가상호스트의이름이기때문에사용해서는안된다. 도메인이름또는 IP 주소를포함하는복수개의태그이다. 가상호스트별로프로퍼티를적용할수있다. JEUS에서정의한프로퍼티들도적용가능하다. 자세한사항은 JEUS Reference Book 의 1.6. 웹엔진프로퍼티 를참고한다. 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. 154 JEUS Web Engine 안내서

5. 3 개의가상호스트를추가한결과가다음과같이화면에나타난다. [ 그림 5.5] 가상호스트추가 - 추가적용결과 콘솔툴사용 콘솔툴을사용하여가상호스트를추가하려면다음과같이 add-virtual-host 명령을수행한다. add-virtualhost 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.7. add-virtual-host 를참고한다. add-virtual-host [-cluster <cluster-name> -server <server-name>] <virtual-host-name> -list <host-name-list> 5.4.2. 수정 WebAdmin 과콘솔툴을사용하여가상호스트를수정할수있다. WebAdmin 사용 WebAdmin을사용하여가상호스트를수정하는방법은다음과같다. 1. WebAdmin 왼쪽메뉴에서 [Servers] 를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하면서버설정화면으로이동한다. 설정화면에서 [Engine] > [Web Engine] > [Virtual Host] 메뉴를선택한다. 가상호스트목록에서수정을원하는가상호스트의이름을클릭한다.([ 그림 5.5] 참고 ) 제 5 장가상호스트 155

2. 설정및설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Virtual Host 설정화면에서설정내용을수정할수있다. [ 그림 5.6] 가상호스트수정 - 기본정보수정 156 JEUS Web Engine 안내서

[Access Log] 메뉴에서가상호스트별로액세스로그를설정할수있다. 자세한내용은절 1.6.10. 가 상호스트별액세스로그설정 을참고한다. 각항목을설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 5.7] 가상호스트수정 - Access Log 추가설정 4. 설정을완료한뒤설정내용의반영을위해 [Activate Changes] 버튼을클릭한다. 제 5 장가상호스트 157

5. 수정내용의반영결과가다음과같이화면에나타난다. 수정내용을반영하려면서버를재시작해야한 다. [ 그림 5.8] 가상호스트수정 - 액세스로그추가적용결과 콘솔툴사용 콘솔툴을사용하여가상호스트를수정하려면다음과같이 modify-virtual-host 명령을수행한다. modify-virtual-host 명령에대한자세한내용은 JEUS Reference Book 의 4.2.8.18. modify-virtual-host 를참고한다. modify-virtual-host [-cluster <cluster-name> -server <server-name>] <virtual-host-name> [-aluph <access-log-use-parent-handler(true/false)> -alf <access-log-format> -aluse <use-access-log(true/false)> -alext <access-log-excluded-extensions>] [-hnrm <host-name> -hnadd <host-name>] 158 JEUS Web Engine 안내서