Apache 핵심 프로젝트 Camel 엿보기

 

본 글은 2013년에 작성한 글임을 인지하고 읽어주십시오. 감사합니다.

 

 

 

• Apache 핵심 프로젝트 Camel 엿보기

   

   

   

   

  
  

 

 

1    Apache Camel    4

1.1    소개    4

1.2    특징    4

1.3    상세 설명    5

1.4    언제 Apache Camel을 써야 하는가?    7

1.5    언제 Apache Camel을 쓰지 말아야 하는가?    8

2    Apache Camel의 컨셉    8

2.1    Route    9

2.2    Component    9

2.3    Endpoint    9

2.4    Producer    10

2.5    Processor    10

2.5.1    Message Transformation    10

2.5.2    Routing    10

2.6    Consumer    11

3    간단한 예제를 통한 다양한 방법 제시    11

3.1    프로젝트 생성    11

3.2    소스 분석    12

3.3    소스 비교    14

3.3.1    Java    14

3.3.2    Java DSL with Camel    15

3.3.3    Spring XML with Camel    15

4    에러처리    16

4.1    에러의 종류    16

4.2    ErrorHandler    17

4.2.1    DefaultErrorHandler    17

4.2.2    DeadLetterChannel    18

4.2.3    LogErrorHandler    18

4.3    에러의 재처리    18

 

 

1. Apache Camel
   1. 소개

• Concise Application Message Exchange Language
• Message Integration Framework
• 이름이 Camel로 지어진 이유가 몇 명의 멤버가 Camel 담배를 즐겨 피우기 때문.
• 낙타는 물 없이도 장거리를 여행 할 수 있는데, 이점이 Camel과 비슷하다. 카멜 프레임워크는 다량의 XML이 담긴 바구니(물을 의미)가 없이도 pure java DSL(Domain Specific language)등을 이용해서 사용 할 수 있다.
• 일반 어플리케이션에 내장 가능한 경량 프레임워크
• Camel의 근본적인 원칙 중 하나는 처리하고자 하는 데이터 타입에 대해 어떤 가정도 하지 않는다는 것이다.
• Camel은 High Level의 추상화를 제공한다. 시스템에서 사용하는 데이터 타입 또는 프로토콜에 상관없이 동일한 API를 사용해서 상호 작용 할 수 있다.

   

1. 특징

• 기업 통합에 없어서는 안될 통합 프레임워크로, 일반적인 어플리케이션에 내장 가능한 경량 프레임워크이다. 프레임워크 내부에 라우터 엔진, 프로세서, 컴포넌트, 메시징 시스템을 포함하여, 어플리케이션의 내부를 외부 세계와 손쉽게 인터페이스 할 수 있게 해준다. 즉, 어플리케이션, 시스템, 서비스들 사이에서 데이터와 기능을 통합하는 중재자 역할을 한다.
• JVM / Java 환경의 오픈 소스 프레임워크인 카멜은 다양한 기술과 프로토콜들을 쓰는 서로 다른 어플리케이션들의 쉬운 통합을 가능하도록 한다.
• 다른 솔루션을 연동하기 위한 어댑터(Camel에서는 Component라고 함)가 있다.
  DB, FTP, HTTP, JMS와 같이 일반적인 어플리케이션 개발에 사용되는 기술에 대한 어댑터를 150여가지 제공(v.2.13.0 기준)한다. 단, 오픈 소스인 만큼 기업에서 많이 사용되는 솔루션의 어댑터는 부족하다.
• 카멜은 ESB나 EAI와 같은 솔루션이라기 보다는 이를 개발하기 위한 Framework로 보는 것이 적절하다. 이유는 ESB나 EAI는 메시지 연동 기능을 수행하기 위한 컨테이너(서버 등)가 존재한다. 아무런 연동 인터페이스가 없더라도, 연동 인터페이스를 수용할 수 있는 컨테이너가 있고, 이 컨테이너들은 모니터링, 로깅등의 관리 기능을 제공한다. 그러나 Camel은 라이브러리다. 자체적으로 컨테이너를 가지고 있지 않다. 다만, WAS, Spring등에 탑재 되어 돌아갈 수 있다. EAI나 ESB는 솔루션 서버를 설치해야 하며, 관리를 위한 관리 콘솔 UI를 제공하지만 Camel은 Jar로 된 라이브러리이므로 Framework 인 것이다. 조사 중 간혹 보이는 글에서는 카멜도 Server가 있다고 하는데(처음 조사에 들어갔을 때 본 글에서 있다고 해서.. 서버 구동에 관한 방법을 찾기도 했다) 그건 Spring이 서버다라고 하는 것과 다를 바 없다.

 

1. 상세 설명

• 카멜은 경량 통합 프레임워크로 모든 EIP들을 실행 할 수 있다. 서로 다른 패턴들을 요구하는 어플리케이션들의 통합이 쉽게 가능해진다.
• Java, Spring XML, Scala or Groovy등이 사용 가능하며, 대부분의 기술들의 사용이 가능한데, 예를 들면 파일을 복사하기 위해서는 Java File Stream API를 사용해야 하고, 데이터베이스를 이용하기 위해서는 JDBC 드라이버를 사용해야 하고, 웹 서비스에 접속하기 위해서는 Apache HttpClient 라이브러리를 사용해야 하고, 이메일을 발신하기 위해서는 JavaMail API를 사용해야 한다. 게다가 새로운 Twitter 서비스를 이용하려 한다면 OAuth에 기반한 Twitter 서비스를 이용해야 한다. 즉 외부 어플리케이션이나, 서비스, 시스템들과 인터페이스 하려는 어플리케이션은 각 인터페이스에 맞는 기술을 어플리케이션 안에 모두 포함해야 한다. 따라서 어플리케이션을 개발하는 개발자가 외부와 인터페이스 하는 각각의 기술에 대한 사용하는 방법을 알아야 한다. 그런데 일반적으로 어플리케이션 개발자는 비즈니스 로직 개발자들이다. 그러므로 외부 세계와 인터페이스에 많은 어려움을 호소하곤 한다. 실제로 인터페이스가 연결되지 않아 비즈니스 로직을 개발이 지연되는 경우가 상당히 많이 발생한다. 다음은 어플리케이션이 다양한 외부 시스템들과 인터페이스 하는 방식을 그림으로 표현한 것이다.

  그러나 어플리케이션이 Camel을 이용하는 경우, 어플리케이션은 Camel을 통해 외부 세계와 인터페이스 할 수 있게 된다. 이 경우 Camel이 어플리케이션을 대신해 외부 세계와 인터페이스 하게 된다. 이런 구조를 갖게 되면 어플리케이션은 Camel의 인터페이스 기술만으로, 어떤 외부 세계와도 인터페이스 할 수 있게 된다. 즉, 비즈니스 어플리케이션 개발자는 Camel 개발자하고만 의사소통하고, Camel 개발자는 인터페이스 하려는 외부 시스템의 개발자와 소통한다. 이 경우 비즈니스를 개발하는 어플리케이션 개발자의 외부 인터페이스에 대한 개발 부담은 현저하게 줄게 될 것이다. 물론 그 부담을 Camel 개발자가 떠안게 되지만, Camel은 외부 인터페이스 연동을 위해 이미 수백 가지 컴포넌트를 제공하고 있으므로, Camel 개발자는 외부와의 인터페이스에 새로운 프로그램을 작성하기 보다 Camel이 제공하는 컴포넌트를 활용할 수 있다. 다음은 Camel을 사용한 어플리케이션의 인터페이스 방식을 그림으로 표현한 것이다.

  

   

1. 언제 Apache Camel을 써야 하는가?

• 만약 서로 다른 기술, 다른 프로토콜들을 쓰는 어플리케이션들을 통합하고 싶다면 쓰는 것이 좋다. Java의 DSL이나 Scala, Groovy 혹은 Spring의 XML을 쓰더라도 가능하다. 왜냐하면 다른 언어와 기술들을 쓰는 어플리케이션들을 같은 컨셉으로 통합시켜주기 때문이다.

  아래 이미지의 윗줄은 Java에서 DSL을 사용하여 쓴 방식이며, 두 번째 줄은 Scala에서 DSL 방식으로 쓴 것이며, 맨 밑줄은 Spring에서 XML방식으로 쓴 것이다. 이를 보아, 언어는 다르지만 컨셉은 같음을 알 수 있다.
  
  또한 각 언어에 대한 에러 핸들링을 지원하며, 자동 테스트도 가능하다. 에러 핸들링은 dead letter queue를 예로 들 수 있으며, 자동 테스트는 Camel-Extension의 JUnit을 통해 쉽고 간단히 할 수 있다. 그저 같은 컨셉으로 기술적인 부담 없이 즐기면 되겠다.

   

1. 언제 Apache Camel을 쓰지 말아야 하는가?

• 분명 Camel이 좋은 프레임워크이긴 하나, 사용하지 않는 것이 좋은 경우도 존재한다. 아래의 이미지는 어플리케이션 통합 시 사용해야 할 적합한 툴을 보여준다.

만약 어플리케이션을 통합하려 할 때, 하나 혹은 두 가지의 기술만을 통합하려 한다면(예를 들어 파일 IO와 JMS message 두 가지만 통합한다면) Apache common IO와 스프링의 JmsTemplate 같은 잘 알려진 라이브러리들을 사용하는 것이 훨씬 쉽고 빠를 것이다.

반면 Camel은 수많은 프로젝트들을 통합할 땐 사용하는 것이 좋지 않다. 이런 경우에는 ESB가 더 적합한 툴이라고 볼 수 있는데, BPM, BAM과 같은 많은 부가적인 자원을 제공하기 때문이다. 물론 단일 프레임워크나 제품을 만들어서 자신만의 ESB를 만들어 사용할 수 있긴 하지만 그건 시간과 돈을 버리는 일이라고 생각한다.

 

1. Apache Camel의 컨셉

• 위에서 수없이 말한 컨셉에 대하여 드디어 설명을 하려 한다. 아래 이미지는 대략적인 도식화를 보여준다.
  

1. Route

• 먼저 Route라는 개념을 이해해야 하는데, Route는 하나의 시스템 간 연동 인터페이스를 정의한다. 예를 들어 시스템 A에서 B로 웹 서비스를 이용해서 연동을 했다면 이것이 하나의 Route가 된다. Route는 1:1 관계뿐만 아니라 1:N의 관계도 지원 하는데, A 시스템에서 B 시스템으로 JMS로 메시지를 보내고, 그 후에 C 시스템으로 FTP 파일 전송하는 인터페이스가 있다면, 이 역시 하나의 Route로 정의할 수 있다.

1. Component

• 각 Route는 크게 Component와 Processor로 정의 된다. 연계 하고자 하는 송신 시스템과 수신 시스템이 있을 때, 각 송신, 수신 시스템의 주소(IP등)을 end point라고 정의하며, Component는 일종의 어댑터의 개념으로, 송수신 시스템의 프로토콜에 맞는 컴포넌트를 선택해야 한다. 예를 들어 송신 시스템을 FTP로 연동하고 싶다면, FTP 컴포넌트를, JDBC로 연동하고 싶다면, JDBC 컴포넌트를 사용해야 한다. 컴포넌트는 송신 시스템으로부터 메시지를 읽어오며, 수신 시스템으로 메시지를 전송하는 역할을 한다.

1. Endpoint

• 시스템은 채널을 통하여 메시지를 송수신 할 수 있다.
• endpoints는 채널의 끝을 모델링하는 추상화이다.
• endpoint는 시스템들을 통합하게 해주는 중립적인 인터페이스 역할을 한다.
• endpoint는 생산자와 소비자를 생성하는 팩토리 역할을 한다. 생산자와 소비자는 메시지를 특별한 endpoint를 위해 메시지를 송수신한다.

1. Producer

• endpoint에 메시지를 생성하고 보낼 수 있는 것으로 메시지를 보낼 필요가 있을 때 producer는 exchange를 생성한다.

1. Processor

• 메시지를 읽고 그냥 보내기만 한다면 별 문제가 없겠지만, 시스템간의 연동에는 메시지를 받은 후에 수신 시스템으로 보내기 전에, 하다못해 로깅을 남기더라도 무엇인가 항상 처리를 한다. 이렇게 송신 시스템으로부터 받은 메시지를 수신 시스템에 보내기 전에 무엇인가 처리를 하는 부분을 Processor라고 하는데, 이 Processor는 그 특징에 따라서 몇 가지로 나뉘어 질 수 있다.

1. Message Transformation

• Format Transformation: 메시지의 포맷을 변경하는 작업을 수행한다. 그 예로는 JSON으로 들어온 데이터를 XML로 변경하는 것들이 해당된다.
• Type Transformation: 데이터 타입을 변경한다. String으로 들어온 메시지를 jms:TextMessageType으로 변경하는 등의 작업을 수행한다. 이러한 메시지 변환은 Java Class를 정의해서 할 수 있으며, 이 외에도 Camel에서 제공하는 Converter나, XSLT를 이용한 변환, Apache Velocity의 Template 엔진 등 다양한 방법을 이용해서 변환이 가능하다.

1. Routing

• 메시지 라우팅은 들어온 메시지를 다수의 수신 시스템에 조건에 따라서 라우팅 할 수 있는 기능이다.
  Processor 단계는 쉽게 생각하면, 메시지를 받은 후, 보내기 전에 무엇인가를 하는 곳이다. 앞서 설명한 것처럼, 메시지를 변환하거나, 라우팅 할 수 도 있고, 로깅을 할 수도 있다. 들어온 메시지에 대해서 유효성 검증을 할 수 도 있다. 이러한 Processor는 자주 사용되는 메시지 변환 등의 패턴은 Camel에 의해서 제공되지만, Java 클래스를 구현하면, 무엇이든지 가능하기 때문에 메시지에 대한 거의 모든 처리를 구현할 수 있는 단계이다.
• 이렇게, 송신 Component -> Processor -> 수신 Component로 하나의 Route가 정의되는데, 이렇게 Route를 정의하여 객체화 시키는 것이 RouteBuilder이다. 이렇게 RouteBuilder에 의해서 생성된 Route는 CamelContext에 바인딩이 된다. CamelContext는 SpringContext와 유사한 개념으로 생각하면 된다. Route에 대한 집합이며, Route에 대한 라이플 사이클(Start up, Stop)등을 관리한다.

1. Consumer

• Exchange로 감싸진 메시지를 수신하는 서비스이다.
• 두 가지 모델이 존재
  • Event-driven consumers
    • 웹 서비스와 같이 컨슈머는 특별한 메시징 채널(TCP/IP, JMS…)을 통해 클라이언트가 메시지를 보내는 것을 기다린다.
    • 메시지가 수신되면 프로세싱을 위해 메시지를 가져간다.
  • Polling consumers
    • 스케쥴을 통해 주기적으로 메시지를 가져간다. 단 이전 메시지가 처리 완료 되지 않았다면 추가 메시지를 가져가지 않는다.
    • FTP, Email, File…

1. 간단한 예제를 통한 다양한 방법 제시

• Camel 프로젝트를 사용하기 위해서는 Maven 사용이 필수이다. 여기선 Maven에 대한 설명은 생략한다.

 

1. 프로젝트 생성

• 가장 먼저 볼 예제는 로컬 파일을 읽어드린 후 다른 경로에 복사하는 간단한 예제이다.
  메이븐을 이용하여 Camel Project를 만든다.
  Copy & paste -> mvn archetype:create -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -DarchetypeVersion=2.5.0 -DgroupId=camelinaction -DartifactId=order-router

  그 후, 메이븐으로 컴파일(mvn –DMainApp compile), 후 실행(mvn –DMainApp exec:exec)한다. 참고로 이클립스에서 메이븐으로 실행하기 위해서는 goals에 exec:java로 해야 한다.

   

1. 소스 분석

• 소스를 보면, 카멜의 최초 시작점이 존재하는데, 바로 Main()이다. 임포트 부분을 보면 카멜에서 지원하는 메인임을 알 수 있다. 그 중, enableHangupSupport()는 camel standalone할 수 있도록 하는 메소드이며, 메인에 routeBuilder를 등록한 후 실행 시키는 것을 볼 수 있다. 다음으로 등록한 RouteBuilder를 보자.
  
• RouteBuilder를 상속받아 재정의 하여 사용 하는 것을 볼 수 있는데, 드디어 위에서 수도 없이 말한 DSL이 등장한다. 지금 쓰인 DSL은 Java DSL로 Route를 효율적으로 정의하기 위해서 camel에 정의된 내장 스크립트 언어이다.
  from이 송신 컴포넌트, choice, when, otherwise는 조건문이며, log처리와 to를 이용한 수신 컴포넌트가 되겠다. 송 수신 컴포넌트는 1:N으로 존재 할 수도 있다. to가 조건문에 있지 않고 밖에 하나 더 있다면 순차적으로 처리 된다. 참고로 파일의 noop 옵션은 소스 파일을 삭제하지 않고 남겨 둔다.

   

1. 소스 비교
   1. Java

1. Java DSL with Camel

• 모든 Camel 어플리케이션은 CamelContext를 사용한다. 제일 처음 본 예제의 경우 스프링의 wrapper class인 Main을 이용한 경우이고, 이번 예제는 Context를 직접 들고 구현한 것이다.

1. Spring XML with Camel

• 위 소스에서 Spring Bean 정의 XML 파일을 main 객체에 지정한 이유는 느슨한 결합(loose coupling이 가능하도록 Camel을 설정하기 위해서이다. 결합도(coupling)를 고려하지 않는다면 Java프로그램 소스 안에 이 XML을 프로그램적으로 삽입 할 수도 있다.
• 카멜의 api docs 주소는 다음과 같다.
  http://camel.apache.org/maven/current/camel-core/apidocs/index.html

   

1. 에러처리

Camel의 에러타입은 Camel이 아니더라도, 일반적인 integration 시나리오에서는 공통적으로 존재하는 에러타입이며, 복구 가능한 에러와 복구 불가능한 에러가 있다.

1. 에러의 종류

• 복구 가능한 에러 (Recoverable error)

  복구 가능한 에러는 다시 시도 했을 경우 정상 처리 할 수 있는 에러이다. 예를 들어 순간적으로 네트워크 Connection이 끊어졌을 때, 대부분 다시 시도하면 재처리가 가능하다.
  Throwable이나 Exception으로 정의하고, Exchange.setException() 메서드를 통해서 바인딩 한다.

• 복구 불가능한 에러 (Irrecoverable error)

  내부 로직 문제나 잘못된 데이터 입력으로 인하여 다시 시도했을 때에도 에러가 예상되는 에러를 복구 불가능 에러로 분리한다.
  Message msg = Exchange.getOut();
  msg.setFault(true)로 설정해 주면, 이 에러는 irrecoverable 에러로 정의된다.

• Camel에서 수신 컴포넌트에서부터 전달되는 메시지는 org.apache.camel.Exchange라는 클래스를 이용해서 전달이 되는데, 에러가 발생하면, 이 클래스에서 에러를 Binding 시킬 수 있다. 에러 처리는 Camel의 Route에 따라서 Channel이라는 단계에서 처리된다.

Camel은 메시지를 수신 받는 Component, 이를 처리하는 Processor, 수신 시스템으로 송신하는 Component로 구성이 된다. 이 세요소 사이에 메시지가 흘러가는데, 이 각각의 구간을 Channel이라고 정의한다. 이 Channel은 단순히 논리적인 구간만이 아니라, 메시지가 흘러가는 길목으로 이 부분을 통해서 에러 처리나 모니터링 등의 작업을 수행 할 수 있다. 즉 에러처리가 여기서 발생한다는 얘기다.

에러가 발생하면, 에러는 전 단계의 Channel로 넘어가게 되고, 정의된 ErrorHandler의 정책에 따라서 에러가 처리 된다. 위의 그림으로 보면, 만약 Processor에서 에러가 발생한다면 Exception은 channel1 부분으로 넘어가면서 정의된 ErrorHandler에 의해 처리 된다. 마찬가지로 outbound component에서 에러가 발생하면 channel2로 넘어가면서 여기서 에러를 처리하게 되는 것이다.

1. ErrorHandler

• Camel은 크게 5개의 ErrorHandler를 가지고 있다.

1. DefaultErrorHandler

• 가장 일반적으로 사용되는 ErrorHandler이다. 에러가 발생하면 앞 단계로 에러를 Propagation한다. 즉, Processor에서 에러가 발생하면 앞 단계의 Inbound Component로 에러를 propagate하고 Route process를 끝낸다. Inbound Component의 경우 내부적으로 자체 Error 처리 로직을 가지고 있는 경우가 있다. (File, FTP, DB Component들의 경우) 이 컴포넌트들은 에러를 받으면 에러 처리를 한 후에 Route를 종료 시킨다.
  만약 특정 에러가 발생하였을 때, Route를 정지 시키지 안고 진행을 하고 싶다면, Error처리를 한 후에 뒤로 진행하도록 할 수 있다.

  

• 위의 코드를 보면 별도의 ErrorHandler를 지정하지 않았기 때문에 Default Handler로 작동하고, StepBackException(모두 임의로 정의한 Exception)이 발생 할 경우, 바로 직전 단계로 Error를 propagate하고 Route를 종료한다.
  HandledErrorException이 발생하면 Handled(true)를 설정했기 때문에, setBody부터의 흐름을 진행하여, des:errorHandle로 메시지를 전달한다.
  IgnoreErrorException이 발생하면, continue(true)에 의해서 에러를 무시하고 .to(des:end)를 그대로 진행한다.

1. DeadLetterChannel

• Error가 발생되었을 때, DeadLetterChannel로 메시지를 전송한다. 일반적으로 Message Queue 메커니즘을 사용할 때 쓰는 일종의 ErrorQueue로 생각하면 된다.

  

  에러가 발생하면 JMS의 error_queue로 전송한다.

1. LogErrorHandler

• 에러가 발생하였을 때, 설정된 Log4j등의 Logger를 통해서 에러를 출력한다.
• 이 외에 TransactionErrorHandler와 NoErrorHandler 등이 있다.
  이 ErrorHandler들은 CamelContext에 적용하여 Context에 binding된 전체 Routeemfdp 적용 할 수도 있고, 개별 Route에만 적용 할 수도 있다.

1. 에러의 재처리

• DefaultErrorHandler의 경우, 에러가 발생하였을 때, 재처리(재시도) 할 수 있도록 설정이 가능하다.

  

  이와 같이 설정하면 5번 Retry를 하게 된다. 이외에 retry 간격, retry시 loggin level 등 옵션을 지정 할 수 있다. http://camel.apache.org/redeliverypolicy.html 을 참조.

/current/camel-core/apidocs/index.html

 

4    에러처리

Camel의 에러타입은 Camel이 아니더라도, 일반적인 integration 시나리오에서는 공통적으로 존재하는 에러타입이며, 복구 가능한 에러와 복구 불가능한 에러가 있다.

4.1    에러의 종류

    복구 가능한 에러 (Recoverable error)

복구 가능한 에러는 다시 시도 했을 경우 정상 처리 할 수 있는 에러이다. 예를 들어 순간적으로 네트워크 Connection이 끊어졌을 때, 대부분 다시 시도하면 재처리가 가능하다.

Throwable이나 Exception으로 정의하고, Exchange.setException() 메서드를 통해서 바인딩 한다.

    복구 불가능한 에러 (Irrecoverable error)

내부 로직 문제나 잘못된 데이터 입력으로 인하여 다시 시도했을 때에도 에러가 예상되는 에러를 복구 불가능 에러로 분리한다.

Message msg = Exchange.getOut();

msg.setFault(true)로 설정해 주면, 이 에러는 irrecoverable 에러로 정의된다.

    Camel에서 수신 컴포넌트에서부터 전달되는 메시지는 org.apache.camel.Exchange라는 클래스를 이용해서 전달이 되는데, 에러가 발생하면, 이 클래스에서 에러를 Binding 시킬 수 있다. 에러 처리는 Camel의 Route에 따라서 Channel이라는 단계에서 처리된다.

 

Camel은 메시지를 수신 받는 Component, 이를 처리하는 Processor, 수신 시스템으로 송신하는 Component로 구성이 된다. 이 세요소 사이에 메시지가 흘러가는데, 이 각각의 구간을 Channel이라고 정의한다. 이 Channel은 단순히 논리적인 구간만이 아니라, 메시지가 흘러가는 길목으로 이 부분을 통해서 에러 처리나 모니터링 등의 작업을 수행 할 수 있다. 즉 에러처리가 여기서 발생한다는 얘기다.

에러가 발생하면, 에러는 전 단계의 Channel로 넘어가게 되고, 정의된 ErrorHandler의 정책에 따라서 에러가 처리 된다. 위의 그림으로 보면, 만약 Processor에서 에러가 발생한다면 Exception은 channel1 부분으로 넘어가면서 정의된 ErrorHandler에 의해 처리 된다. 마찬가지로 outbound component에서 에러가 발생하면 channel2로 넘어가면서 여기서 에러를 처리하게 되는 것이다.

4.2    ErrorHandler

    Camel은 크게 5개의 ErrorHandler를 가지고 있다.

4.2.1    DefaultErrorHandler

    가장 일반적으로 사용되는 ErrorHandler이다. 에러가 발생하면 앞 단계로 에러를 Propagation한다. 즉, Processor에서 에러가 발생하면 앞 단계의 Inbound Component로 에러를 propagate하고 Route process를 끝낸다. Inbound Component의 경우 내부적으로 자체 Error 처리 로직을 가지고 있는 경우가 있다. (File, FTP, DB Component들의 경우) 이 컴포넌트들은 에러를 받으면 에러 처리를 한 후에 Route를 종료 시킨다.

만약 특정 에러가 발생하였을 때, Route를 정지 시키지 안고 진행을 하고 싶다면, Error처리를 한 후에 뒤로 진행하도록 할 수 있다.

 

    위의 코드를 보면 별도의 ErrorHandler를 지정하지 않았기 때문에 Default Handler로 작동하고, StepBackException(모두 임의로 정의한 Exception)이 발생 할 경우, 바로 직전 단계로 Error를 propagate하고 Route를 종료한다.

HandledErrorException이 발생하면 Handled(true)를 설정했기 때문에, setBody부터의 흐름을 진행하여, des:errorHandle로 메시지를 전달한다.

IgnoreErrorException이 발생하면, continue(true)에 의해서 에러를 무시하고 .to(des:end)를 그대로 진행한다.

4.2.2    DeadLetterChannel

    Error가 발생되었을 때, DeadLetterChannel로 메시지를 전송한다. 일반적으로 Message Queue 메커니즘을 사용할 때 쓰는 일종의 ErrorQueue로 생각하면 된다.

 

에러가 발생하면 JMS의 error_queue로 전송한다.

4.2.3    LogErrorHandler

    에러가 발생하였을 때, 설정된 Log4j등의 Logger를 통해서 에러를 출력한다.

    이 외에 TransactionErrorHandler와 NoErrorHandler 등이 있다.

이 ErrorHandler들은 CamelContext에 적용하여 Context에 binding된 전체 Routeemfdp 적용 할 수도 있고, 개별 Route에만 적용 할 수도 있다.

4.3    에러의 재처리

    DefaultErrorHandler의 경우, 에러가 발생하였을 때, 재처리(재시도) 할 수 있도록 설정이 가능하다.

 

이와 같이 설정하면 5번 Retry를 하게 된다. 이외에 retry 간격, retry시 loggin level 등 옵션을 지정 할 수 있다. http://camel.apache.org/redeliverypolicy.html 을 참조.