[오픈소스컨설팅]JBoss 5 Detail

JBoss Application Server
Open Source Consulting, Inc.

Ji-Woong Choi, Consulting Coach(jchoi@osci.kr)

©2012 Open Source Consulting, Inc.
The information contained herein is subject to change without notice
Copyright 2012 , Open Source Consulting, Inc. All Right Reserved 0

Java Enterprise Edition

J2EE 1.3 J2EE 1.4 JEE5 JEE6


Genesis of Java

우리 가전 제품을 제어할
소프트웨어를 만들어 주세요
1991년

제품마다 칩이 틀리고 C언어를
이용하여 새로 컴파일하니 시간이
너무 오래 걸리네.
어떠한 OS에서도 돌릴 수 있는
방법이 없을까?

밥솥, 냉장고 등에 넣어야 하기 때문에 어떠한 OS에서라도 동작해야 한다!!(Platform 독립)

Java탄생

Java 2 Enterprise Edition

규모 EJB

Servlet stands for

1998년
Applet

1996년

넷스케이프를 통한 웹 중흥

HTTP등장

TCP/IP


Genesis of EJB(1998)

원격호출을 쉽게
해볼까?

Java RMI
+
RMI(Remote Method Invocation) CORBA Service
(원격지에 있는 객체를 내 것처럼)

CORBA EJB
1.분산 트랜잭션 (Enterprise Java Beans)
2.디렉토리 서비스 JSR-19
3.네이밍 서비스
4.보안 서비스
5.기타 등등.
뭔가 부족합니다!
CORBA가 좋군요!


First Web Application Server : Tengah

• WebLogic, Inc.
 1995년 자바 탄생과 동시에 설립
 1997년 Pure Java RMI/ORB 서버 Tengah 개발
 CORBA, 오라클 데이터베이스, MSSQL 서버, dbKona/Sybase 등에 접근을 쉽게 제공
 애플릿에서 데이터베이스 연결을 허용하는 ‘Three-tier’ 서버도 개발(웹로직의 t3
프로토콜은 three-tier server란 이름에서 변형.)
 1998년 BEA Systems에 인수(C기반 TP모니터 턱시도)
 2008년 오라클 인수


WAS Market



• Enterprise Java Beans Open Source Software
 1999년, 프랑스의 엔지니어였던 마크 플러리(Marc Fleury)에 시작된 오픈소스
 프로젝트는 J2EE 명세서의 Enterprise Java Bean (EJB) 부분에 대한 구현체 제공을
목적
 2001년 플러리와 동료들(Apache Tomcat Committers)은 JBoss Group, LLC
설립(커뮤니티 지원, 교육, 컨설팅으로 사업)
 EJB는 Sun의 상표권으로서 이름을 사용하지 못함
 전세계에 개발자를 둔 오픈소스 웹 애플리케이션 서버
 2006년 레드햇 인수(RHEL과 같은 전략을 취함)


JBoss Community vs Enterprise Edition

JBoss.org Community JBoss Enterprise Middleware


JBoss Enterprise Application Platform

1 2 3 4 5
Delivery Phase

JBoss.org 프로젝트 제품 요구 사항 정의 플랫폼 컴포넌트 플랫폼 테스팅, 인증, 문서화 플랫폼 발표

구성 및 통합 (General Availability)

Platform JBoss
Quality
Candidate Enterprise
Productization Team

Assurance
Release(s) Platform

제품 관리 JBoss JBoss QA, 문서화팀, JBoss Release
Engineering
제품화 담당 엔지니어 인증된 파트너


Global Community Collaboration

이런 상황에서 손쉽게
개발자는 전세계에
JBoss 기능을 확장시킬
존재하고, 모여서
수 있는 방법이
협업하기도 힘들어~
무엇일까?


JBoss 4.X – Micro Kernel

• POJO 스타일로 Service와 Deployer로 구성하여 상호 참조가 가능하는 것이 목적.
• 구성 요소
 MbeanServer : JBoss 부팅시 로드되도록 함.
 JBoss JMX : 모든 서비스들이 JMX 버스에 등록되도록 함.
 Services : 서버구성 컴포넌트들(예: HttpService, EJBService, Scanner, Messaging Service 등)
 Deployers : 사용자가 만들 애플리케이션이 나타났을 경우, 어떤 서비스에 적용할 것인지 제어하는 컴포넌트(예:
xxx.war가 등록되면 확장자를 통해 WarDeployer가 구동되고, 해당 HttpService를 찾아 호출해주는 기능을 담당)
 ClassLoader : deployer에 의해 등록되는 애플리케이션을 위한 클래스 로더


JBoss 5.X – Microcontainer

• 2005년 마이크로 컨테이너로 이름을 변경하고 부가 기능들을 도입
 기본 마이크로 커널 기능
 auto-wiring(by javassist)
 inner bean/local bean
 prototype bean
 Module(OSGi like)
 reusable bean (abstract bean/function)
 ad-hoc bean combination



보다 더 유연한 구조로 시스템을 확장하여 새로운 프레임워크를 만들 수 있도록 구성

 WAS의 core 기능을 모듈화함 APIs / Programmings Models
 최소의 기능을 가진 Container (POJOs, WS, REST, Java EE, Spring, Groovy, jRuby, etc.)

 Microcontainer는 많은 컴포넌트
모델을 지원

Web Services
Transactions
 POJO

Persistence
Messaging

Clustering
Remoting
Caching

Security
 JMX
 OSGI 등
 공통된 관리 기반 제공
 필요한 기능을 만들어 넣을 수
Core Enterprise Services
있는 Pluggable 한 구조
JBoss MicroContainer
(Dependencies, Lifecycle, Management, Class-loading)

Java Virtual Machine



• JBoss의 다양한 플러그인들을 마음대로 가져다 쓸 수 있음.
 Spring의 경우 하나의 jar 또는 context로 묶어야 동일 클래스 로더에서 참조 가능
• 서로 다른 클래스 로더에 의해 로딩된 클래스라도 Kernel Bus에 의해 참조 가능
• 애플리케이션을 작은 모듈 단위로 나누어 필요할 때 커널에 꽂아 사용하면 됨.

2 새로운 버전의 서비스
등록시 버전 등록을
1 새로운 버전의
통하여 이력 관리
Jar, Sar 애플리케이션 Service
서비스 등록
(New version)
Workflow
Application
(New Version) DB
Service Connec
tion
Workflow Pool-1
Application
DB
Connec DBMS
Service tion
Pool-2

DB
Service Version Description Service Connec
tion
R2R 1.0 Initial Version Pool-n

R2R 1.1 Minor Upgrade



클래스 리로딩은 커스텀 클래스 기능을 사용하지 않으면 구현할 수 없는 기술

Bootstrap • 부트스트랩 클래스로더는 JVM의
lib/rt.jar ClassLoader
네이티브 코드 영역에 존재하며,
Object와 같은 코어 자바 클래스를
Ext 바이트코드
/jre/lib/ext VM에 로딩할 때 사용
ClassLoader 조작

• 익스텐션 클래스로더(extension
App 클래스 로더 저장
객체 생성 classloader)라고도 불리며, 자바의
ClassLoader
확장 클래스들을 로딩할 때 사용

• java.class.path 프로퍼티에 명시된
Custom Custom 경로에서 코드를 로딩하는
ClassLoader Class Loader
클래스로더
Workflow Manager

JBoss Microcontainer


JBoss 7.X – OSGi

• Open Service Gateway initiative
• 원래 홈게이트웨이 용도로 시작, 스마트폰, 가전제품, 산업 자동화, 자동차 분야까지 확대
• Sun JCP JSR-291 (Dynamic Component Support for Java™ SE - 별칭: OSGi 4.1)
• Modularity(모듈화)
 OSGi내의 모듈을 정의
OSGi Framework
 다른 모듈을 위한 기능 제공
 다른 모듈에 의해 제공되는 기능 사용
Service
registry
Bundle Bundle
packages
packages

JAVA

Operating System

Hardware


JBoss 7.X – OSGi

BundleActivator의 start()
메소드 호출
번들이 정상적으로 디플로이

시작이나 종료될 준비가 된
상태인지 확인 BundleActivator의 start()
메소드 호출 후 정상적인 메시지 리턴시

BundleActivator의 stop()
메소드 호출


JBoss Servers

• minimal
최소 설정 - JBoss 시작에 필요한 최소한만 포함되어 있음. 로깅,
JNDI서버, URL 디플로이먼트 스캐너만 포함됨. 웹 컨테이너나
EJB, JMS지원은 포함되지 않음.
• default
기본 Java EE 5 서버 프로파일. Java EE 애플리케이션
디플로이시 자주 사용되는 기본적인 구성요소를 포함함.
JAXR서비스, IIOP서비스, 클러스터링 관련 서비스는 미포함
• all
모든 사용 가능한 서비스가 포함되어 있음. RMI/IIOP와
클러스터링 등을 포함함
• standard
JavaEE 5 인증을 받은 JBoss 구성
• web
경량 웹컨테이너 기반의 서비스(Java EE 6 웹 프로파일을 미리
맛볼 수 있음)


Instance Directories

디렉터리 설명

conf bootstrap.xml 부트스트랩 디스크립터를 포함하고 있음. 서버가 살아있는 동안 계속 존재할 핵심 마이크로컨테이너 빈을 정의

파일시스템에 내용을 저장하고 싶은 서비스가 사용할 디렉터리. 서버 재시작시에 다시 복구해야 할 영속성이 있는 데이터들을
data
저장함. 예를 들어 Hypersonic 데이터베이스 인스턴스와 같은 서비스들이 데이터를 여기 저장

핫 디플로이(서버 실행 도중 추가/삭제 되는 것을 말함) 가능한 서비스들을 저장함. 현재 서버 설정에서 사용되는
deploy
애플리케이션을 포함함. 사용자는 이 디렉터리에 애플리케이션 패키지를 복사해서 자동으로 디플로이할 수 있음

이 서버 설정에 필요한 JAR 파일을 포함함. JDBC 드라이버 등의 필요한 라이브러리 파일이 여기 저장되며, 서버 시작시
lib 공유된 클래스패스에 이 디렉터리에 있는 JAR파일들이 포함됨. 다만, 이 디렉터리에는 특정 서버 설정에서 사용할
라이브러리만 저장하며, 여러 설정에서 공유되는 JAR들은 <JBoss_Home>/common/lib에 들어가게 됨.

로그파일이 저장되는 디렉터리. Jakarta log4j 패키지를 사용해 로깅을 함. 로깅 관련 설정은 conf/jboss-log4j.xml 설정파일로
log
변경 가능함

tmp 서비스에서 사용하는 임시파일이 저장됨. 예를 들어 디플로이어들은 압축된 파일을 이 디렉터리에 풀어서 처리

work Tomcat이 JSP파일을 컴파일한 자바파일과 클래스파일이 이 디렉터리에 들어감


Processing for Heavy Load

• JBoss Application Server는 Thread Pooling 기법을 이용하여 성능 향상을 구현하고 있으며, 미세한 XML 환경 설정
조정을 통한 스레드 조절이 가능함으로써 성능 향상을 위한 튜닝을 효과적으로 진행

• JSP/Servlet에 대한 Pool을 이용하여 성능을 극대화.
• EJB의 경우 Pool을 이용하여 init, max 영역 내에서 자동으로 조절할 수 있는 기능을 보유
• JDBC Pooling을 이용한 데이터 베이스 커넥션 재사용


EJB Pool
Request
Pooling DB Connection
DBMS
EJB Pool Pooling
Queue
EJB JDBC
Request
Thread Pool

Execute Thread
Execute Thread
Execute Thread

Pooling


Data Source

9


Server 1번
WebServer Request DBMS
2 접속
수행 Data
1
Source 1 DBMS1
HA 3 1번
DBMS
Data Fail 확인
웹컴포넌트 Source
5 Data 7 응답
2번 Connection Source 2
Pool로 6 2번
DBMS2
재 Request 수행 DBMS
접속

 Deploy/ 디렉토리 하위의 *-ds.xml 파일이 존재할 경우 내부의 XML설정을 이용하여 JNDI 맵핑
 Pool에 유지할 최소 connection 개수로 기본값은 0. 기본적으로 최초 getConnection() 호출전까지 물리적인 db connection은
만들어지지 않음. 데이터소스 디플로이시에 <min-pool-size>만큼 connection을 만들고자 한다면 <prefill>true</prefill>을
추가로 설정해야 함.
 JBoss가 자동으로 leak을 발생하는 statement 객체를 자동으로 닫고자 할 경우 <track-statements>를 true로 설정
 JDBC preset statement 성능향상을 위해 <prepared-statement-cache-size>를 설정: specj에 의하며 10% 정도의 성능
향상이 보고됨.


Java Management Extension

JMX를 이용할 경우 모든 소프트웨어 관리 포인트를 한 곳으로 집중할 수 있다는 장점이 발생.(JSR-255)
 모든 리소스는 MBean을 사용하여 관리.
 JMX Agent (or group of agents)상의 모든 MBean은 하나의 관리 콘솔에서 모두 처리

Firewall hardware

Server
JMX Agent

Web server software

Server Application

Management console
DB server software Adapter

= JMX MBean

http://www.jcp.org/en/jsr/detail?id=255
JSR 255: JavaTM Management Extensions (JMXTM) Specification, version 2.0


Logging

• JBoss 서비스 중 가장 먼저 올라오는 서비스 중의 하나(참조: conf/jboss-service.xml)
• /conf/jboss-log4j.xml 파일에 log4j 관련 appender를 설정하여 로그 설정
• SMTPAppender, SocketAppender, JMSAppender, SyslogAppender 사용 가능)
• JBoss 에서는 기본적으로 INFO로 세팅되어 있음.
• 서버 로그는 logs/server.log 파일에 기록됨
• 로그 레벨의 변경
 /conf/jboss-log4j.xml 파일을 수정 가능
 파일의 수정보다는 start script에서 시스템 프로퍼티를 사용하여 변경 권장
 -Djboss.server.log.threshold=DEBUG


JBoss Web Tier

• 3-Main Connectors : HTTP 1.1, HTTPS, AJP 1.3
JBoss Web
JSP JMX
HTTP
Servlet
API
HTTPS

AJP

• HTTP 1.1
 Application Server로의 direct request를 받음
 Default: enabled, port: 8080
• HTTPS
 HTTPS를 직접 입력으로 받음, SSL keystore 필요
 Default: disabled, port: 8443
• AJP 1.3
 Apache Web Server를 통해 mod_jk를 통해 입력받는 커넥터
 Default: enabled, port: 8009


JBoss Web Tier Configuration

• Tomcat Chairman == JBoss Web Project Lead
• deploy/jbossweb.sar/server.xml
• IP 주소에 따른 바인딩이 결정됨
 server.xml - ${jboss.bind.address}
 서버 시작시 – run.sh –b 명령


<Connector protocol="HTTP/1.1" port="8080" address="${jboss.bind.address}"
connectionTimeout="20000" redirectPort="8443" />




<Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}"
redirectPort="8443" />

JNDI Service Configuration

• conf/jboss-service.xml 파일에 서비스 기술
• IP 주소에 따른 바인딩이 결정됨 : ${jboss.bind.address}
• JNDI lookup은 프로그래밍적으로 처리하거나, 클래스 패스 내의 jndi.properties 파일을 사용
 java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
 java.naming.provider.url=jnp://localhost:1099

• IP HTTP/S를 통해 터널링 시킬 수 있음
• 클러스터 구성시 HA-JNDI 서비스 가능
 TCP 1100이 기본적으로 사용됨
 java.naming.provider.url=server:1100,server2:1100,server3:1100


JMS - Messaging

• JBoss Messaging Main
 JMS 1.1 스펙 준수 및 JBoss AS의 런타임 라이브러리로 사용.
 성능, 신뢰성, 안정성 및 낮은 응답시간 등에 초점을 둠.
 SOA의 초기 단계인 JBoss ESB의 핵심 모듈로서 사용
 Netty 기반의 고성능 자바 엔진(LDAP, DNS, Keberos, etc)

Client-side Delegates

?
Connection
Sender Receiver

Session
JBoss
Netty
Core
Producer
Server-
side
aspects
Consumer

Client-side aspects Server-side
endpoints


JMS - Messaging

• deploy/messaging 파일에 서비스 기술
• 아래와 같은 설정 파일들이 존재
 messaging-service.xml – Microcontainer 서비스 등록에 대한 설정
 remoting-bisocket-service.xml – clientserver로 접속할 때 소켓을 설정
 xxx-persistence-service.xml – DB persistence를 사용할 경우 지정
 connection-factory-service.xml – 메시징 커넥션 팩토리 설정
 destinations-service.xml - Queue/Topic에 대한 설정


HTTP Tunneling

• 방화벽으로 인하여 서비스를 정상적으로 처리하지 못할 경우 사용 가능

JNDI JNDI
Application
Client HTTP Server
RMI RMI

• JBoss의 invoker 서비스를 이용하여 터널링을 처리
• deploy/http-invoker.sar 애플리케이션에 JBoss에 터널링 액세스를 지원하는 모든 컴포넌트 제공
• sar 내의 META-INF/jboss-service.xml 파일 내의 HttpInvoker 및
HttpInvokerHA(all 설정) 정의
• jndi.properties의 내용은 다음의 내용으로 변경 필요
 java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
 java.naming.provider.url=https://localhost:8443/invoker/JNDIFactorySSL


Classloading

System Class Loader

Enterprise Application
Archive(EAR)
EAR Class Loader

Resource Adaptor
Archive(EAR)
RAR Class Loader

Web Application
Archive(EAR)
WAR Class Loader

• 애플리케이션 디플로이시 가장 많은 문제를 일으킴
• 아래의 코드를 통해 클래스 로더를 분리
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>
com.samsung:archive=com.stsm.iis.war
</loader-repository>
</class-loading>
<context-root>/</context-root>
</jboss-web>


Load Balancing

일반적으로 안정성 및 성능 지향적인 업무 시스템을 위한 하드웨어 구성을 위하여 Web 서버 및 Web Application
서버 플랫폼의 하드웨어를 이중화하는 구성을 사용

Web 서버 JBoss AS DB 서버

DBMS

내부 망/외부 망
Load
Balancer

DBMS

부하분산 흐름도

* DB 서버의 구성에 따라, JBoss Server가 하나의 업무 DB를 접속하거나,
이중화된 DB를 접속할 수 있도록 구성할 수 있습니다.


Load Balancing

JBoss는 애플리케이션 서버 자체의 클러스터링 기능을 이용하여 HTTP Sessio에 대한 클러스터링 및 Stateful EJB에 대한
클러스터링을 통하여 처리 속도를 향상 시킬 수 있는 방법을 제공.

Source JBoss Application Server Data
3

1 2

Load
Balancer
부하분산 흐름도

 HTTP Load-balancing
 L4 또는 Apache Plug-in (mod_jk)를 사용
 Apache Plug-in (mod_jk) Load-balancing 정책
 Weighted Round Robin, Lowest Session, Lowest Network Traffic, Lowest Current Load
 EJB Load-balancing(EJB Stub (Proxy)에서 제어)
 Load-balancing 정책
 Round Robin – 매번 다른 노드를 호출 (Stateless Session Bean)‫‏‬
 First Available – 처음 선택된 노드를 계속 호출 (Stateful Session Bean, Entity Bean)‫‏‬
 First Available with Identical All Proxies – 처음 선택된 노드를 계속 호출하며, 동일한 EJB를 호출하는 모든 클라이언트는 이 노드를 호출


Clustering

• JBoss Cache 및 JGroups 컴포넌트를 통해 Clustering 기능을 제공
• Configuration: all/deploy/cluster/jboss-cache-manager.sar

 부하 분산: 요청을 서버들에 전달하여 고가용성 및 성능향상
 상태 복제: 클러스터 내의 모든 노드들이 상태 접근가능 – 하나의 노드가 장애시 다른 노드에서 클라이언트와 통신하여 서비스 제공
 자동 장애복구: 시스템 장애시 클라이언트는 다른 노드로 redirection

정상 서비스 수행(세션 복제) 장애 발생으로 인한 세션 Fail-Over 수행

Main HttpSession Main HttpSession
JGroups JGroups
Buddy HttpSession Buddy HttpSession
WAS
WA
클러스터링된 JBoss S 장애 발생시 Buddy 그
M1 Server간의 HttpSession 룹에 저장된
M1 HttpSession을 이용하
Web 복제가 이루어짐
Server 여 계속 처리
Failover
Web
Plug-in
Client Server
WAS Plug-in
Client WA
S
M2
(주요사항) M2
클러스터링이 되어있는 모든 클러스터A
클러스터A
JBoss Server는 실시간 Domain Domain
으로 정보를 주고 받습니다.


Custom Clustering

기본적으로 WAS에서 제공하는 클러스터링을 이용하지 못하고 자체적으로 구축해야 하는 경우, 멀티캐스트 솔루션과 캐시
솔루션을 이용하여 분산 복제 애플리케이션을 구축

Workflow
1
App
Workflow

2
Replication
Proxy

AppContext
(Cache)

Database A
3 Workflow
JGroups App
Workflow

4
Replication
AppContext
(Cache)

1 클라이언트 프록시에 의해 서버 1의 애플리케이션이 호출됩니다. 공유해야 할 정보를 컨텍스트에 복제합니다.

2 컨텍스트가 변경된 것을 캐시가 자동으로 감지합니다.

3 JGroups 등의 멀티캐스트 솔루션을 통해 같은 그룹내에 있는 클러스터 노드로 변경된 데이터를 복제합니다.

4 노드 1번에 문제가 발생했을 경우 노드 2번에 동일한 데이터가 컨텍스트에 존재하게 됩니다.


Apache Modules & JBoss Web

• Load Balancing을 위한 3가지 아파치 모듈
 mod_jk - 가장 오래되고 안정됨
 mod_proxy – Apache 2.2 이상에서 사용가능, mod_proxy_ajp, mod_proxy_balancer 등이 필요없음
 mod_cluster – 새로운 형태의 모듈, multicast를 통한 자동 발견 기능 등
• JBoss Web 설정
 AJP 1.3 Connector에 가장 최적화 되어 있음
 Deploy/jbossweb.sar/server.xml 설정의 8009 포트 사용.
 jvmRoute 속성을 통해 Apache Worker 이름을 정의
 요청 유입시 maxThreads 속성의 값까지 스레드 생성, 이후 요청 유입은 acceptCount 값까지
 Access Log를 통하여 Request 내역 및 처리 정보 확인 가능

<Valve className="org.apache.catalina.valves.AccessLogValve“ prefix="localhost_access_log." suffix=".log“
pattern="common" directory="${jboss.server.log.dir}“ resolveHosts="false" />

https://community.jboss.org/wiki/OptimalModjk12Configuration

AJP Connector

• 다양한 Test를 통하여 환경에 맞는 Tuning Point를 확인 필요
• /deploy/jbossweb.sar/server.xml
• AJP Connector 주요 Tuning Point

<Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}“ redirectPort="8443" />

• maxThreads : Connector에서 생성되는 request processing thread의 최대값 및 최대 동시 처리량을 의미.( default : 200 )
• maxPostSize : HTTP POST request size ( default : 2MB )
• backlog : 모든 request processing thread가 작동중일 경우 connection request를 저장하는 queue lenghth ( defalut : 10 )
• connectionTimeout : connection을 수락한 후 Request URI을 받을 때까지 Connector가 기다리는 시간 default : unlimited )
• keepAliveTimeout : connection을 종료하기 전에 또 다른 AJP request를 받을 때까지 Connector가 기다리는 시간 ( default :
connectionTimeout 값 )

mod_jk

• Connection Directives
 socket_timeout : JK에서 Remote Host로부터의 response를 유지하는 시갂 ( default : 0 )
 ping_mode, prepost_timeout, connect_timeout : AJP13의 CPing, CPong packet을 이용하여 back-end 서버가
정상적으로 connection이 연결되어 서비스 하고 있는지 확인
 lbfactor : load balancer의 member worker의 request 처리량 할당 ( default : 1 )
 connection_pool_size : 각 웹서버 child process 당 pool로 유지하는 AJP back-end connection 수
• Load Balancing Directives
 method : request 수, session의 개수, network traffic, busyness 등 Load Balancing 수행 시 최적의 worker를 찾는
알고리즘을 선택 ( default : Request )
 sticky_session : SESSION ID를 포함한 request를 같은 worker로 전달할건지 결정 (default : true )
• Advanced Worker Directives
 recovery_options : 장애 발생시 처리 방식 선택 ( 중복 선택 가능, default 0 )
 1: don't recover if Tomcat failed after getting the request
2: don't recover if Tomcat failed after sending the headers to client
4: close the connection to Tomcat, if we detect an error when writing back the answer to the client (browser)
8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are set) – 1.2.24이후
16: always recover requests for HTTP method GET (even if Bits 1 or 2 are set) – 1.2.24이후
http://tomcat.apache.org/connectors-doc/reference/workers.html


Written by
Open Source Consulting, Inc


[오픈소스컨설팅]JBoss 5 Detail

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (6)

Similar a [오픈소스컨설팅]JBoss 5 Detail

Similar a [오픈소스컨설팅]JBoss 5 Detail (20)

Más de Ji-Woong Choi

Más de Ji-Woong Choi (20)

[오픈소스컨설팅]JBoss 5 Detail