Apache ServiceMix

[원문출처] http://camel.apache.org/error-handler.html

해당 문서의 경우 Apache 재단의 Camel Document 문서 일부를 번역 한 것입니다. 
번역본인 해당 문서의 경우 역자에게 있음을 알리며 상업적 이용을 불허합니다. 

www.sogomsoft.co.kr (주) 소곰소프트 

에러 핸들러(Error Handler)

Camel은 이벤트 기반 Consumer가 에러 처리하는 것을 다루기 위해 플러그인 가능한 ErrorHandler 전략들을 제공한다. 예외 절(Exception Clause)를 사용하여 DSL에서 직접 에러 핸들링을 지정하는 것은 선택적이다.  

소개와 배경 지식를 위해  Error handling in Camel 을 보라.

현재 Camle 구현체들이 다음 특별한 기능을 제공한다. :

비 트랜잭션 (Non transacted : 트랜잭션을 지원하지 않는)

• DefaultErrorHandler 는 Camel 에서 기본 에러 핸들러이다. 이 에러 핸들러는 데드 레터 큐(dead letter queue)를 지원하지 않고 호출한 곳에 exception을 전달하게 될 것이다. 만약 전혀 에러 핸들러가 없다면 Features의 설정에 제한을 가진다.
• Dead Letter Channel 는 데드 레터 엔드포인트에 보내기 전에 메시지 교환의 횟수를 재 전송하기 위해 시도하는 것을 지원한다.
• LoggingErrorHandler는 단지 Exception을 잡아내고 로깅하기 위한 것이다.
• NoErrorHandler 는 어떠한 에러 핸들링도 없는 것이다.

트랜잭션 (Transacted : 트랜잭션을 지원하는)

• TransactionErrorHandler는 트랜잭션을 지원하는 라우터를 위한 Camel에서 기본 에러 헨들러이다.  Transactional Client EIP 패턴을 보라.

에러 핸들러들은 다음 예에서 보여주는 것처럼 DSL에서 룰 전체 또는 특정 라우팅 룰에 지원 될 수 있다. 에러 핸들러 룰들은 단일 RouteBuilder 안에서 각각 라우팅하는 룰 위에 상속 된다. 

제공되는 에러 핸들러의 간단한 요약

DefaultErrorHandler

DefaultErrorHandler 는 Camel 에서 기본에러 핸들러이다. Dead Letter Channel 와 다르게 어떠한 데드 레터 큐(dead letter queue)를 가지고 있지 않다. 그리고 기본적으로 Exception들을 핸들링 하지 않는다.

Dead Letter Channel

Dead Letter Channel은 1초 딜레이를 사용하여 최대 6번의 재 전송을 할 것이다. 만약 exchange가 실패 하면 ERROR 레벨에 로깅 될 것이다.

사용하기 위해 기본 데드 레터 엔드포인트를 환경 설정 할 수 있다. :

또는 in Spring DSL 에서

또는 Camel 2.3.0 이후 부터 또한

Logging Error Handler

로깅 에러 핸들러는 캐치되지 않은 Exception이 던져 질 때 마다 기본적으로 ERROR 레벨에 로깅 될 것이다. 로깅 카테고리, 로거, 레벨은 빌더에서 모두 정의 될 수 있다.

또는 Spring DSL 에서

또는 Camel 2.3.0 이후 부터 또한

이것은 카테고리는 mylogger.name 을 사용하여 에러 핸들러를 생성하게 되고 그리고 모든 로그 메시지를 생성하기 위해 INFO 레벨을 사용한다.

또 로거는 특정 라우터를 위해서 정의 될 수 있다. may also be defined for specific routes.

No Error Handler

no error handler는 에러 핸들링을 비활성화 하기 위해 사용된다.

또는 Spring DSL에서

또는 Camel 2.3.0 이후 부터 또한

TransactionErrorHandler

TransactionErrorHandler는 Camel에서 트랜잭션이 적용된 라우터를 위한 기본 에러 헨들러이다. 

다양한 Error Handlers의 기능들을 지원한다.

Error Handler(들)에 의해 지원되는 기능이 여기 있다. :

위 기능들의 일부의 문서는 Exception 절(Exception Clause) 문서를 보라.

Scopes

에러 핸들러의 스코프는 다음 중 하나 이다.

• global
• route 당

다음 예는 어떻게 글로벌 에러 핸들러를 등록하는지를 보여준다. (이 경우에서는 logging handler를 사용한다.)

다음 예는 어떻게 라우터에 특정 에러 핸들러를 등록할 수 있는지를 보여 준다. 커스터마이징 된 로그 핸들러는 단지 Endpoint seda:a로 부터 라우터를 위해서 등록된다. 

Spring 기반의 환경 구성

에러 핸들러는 스프링 빈과 다음 스코프 에서 처럼 환경 구성 될 수 있다. :

• global (camelContext 테그)
• route 당 (route 테그)
• policy 당 (policy/transacted 테그)

에러 핸들러는 errorHandlerRef 속성으로 환경 구성 될 수 있다.

Spring 기반 환경 구성 예제

이 예에서 라우터에서 최종 3번과 재시도 전에 약간의 딜레이로 재전송하는 라우터에서 Dead Letter Channel 을 환경 구성한다.

먼저 route 테그에서 errorHandlerRef 속성을 사용하여 myDeadLetterErrorHandler 에 참조를 환경 설정한다..

그리고 Dead Letter Channel인 스프링 bean 엘리먼트를 사용하여 표준 스프링으로  myDeadLetterErrorHandler를 환경 구성한다.

그리고 마지막으로 얼마나 많이 재전송할 것인지 지연시킬 것인지 등을 위한 옵션을 환경 구성할 재전송 정책을 위한 다른 Spring 빈을 가진다.

Camel 2.3.0 부터, Camel은 에러 핸들러를 위하여 customer 빈 환경 구성을 제공한다.  여기 예제가 있다.

트랜잭션을 지원하는(transactional) 에러 핸들러 사용

트랜잭션 에러 핸들러는 스프링 트랜잭션을 기반으로 되어 있고 camel-spring component의 사용을 필요로 한다..
사용하는 방법과 에러 핸들러로 환경 구성하는 트랜잭션 행위와 환경 구성을 위한 많은 예가 있는 Transactional Client를 보라.

See also

• Error handling in Camel  (Camel에서 에러 핸들링에 소개 또는 배경 지식 자료를 위한)
• Dead Letter Channel (데드 레터 에러 핸들링을 위한)
• DefaultErrorHandler (Camel에서 기본 에러 핸들러를 위한)
• TransactionErrorHandler (트랜잭션이 적용되는 라우터의 기본 에러 핸들러를 위한 )
• Transactional Client (트랜적션 행위를 위한)
• Exception Clause (던져진 exception을 핸들링 하는 것을 지원을 위한)
• Try Catch Finally  (라우팅에 사용될 DSL로 try ... catch ... finally 를 위한)

[원문출처] http://camel.apache.org/error-handling-in-camel.html

해당 문서의 경우 Apache 재단의 Camel Document 문서 일부를 번역 한 것입니다.
번역본인 해당 문서의 경우 역자에게 있음을 알리며 상업적 이용을 불허합니다. 

www.sogomsoft.co.kr (주) 소곰소프트 

Camel에서 에러 핸들링 (Error handling in Camel)

카멜에서 에러 핸들링을 하는 방법은 대략 두가지 유형으로 구분 된다. :

• non transactional (트랜잭션이 적용되지 않는)
• transactional(트랜잭션이 적용되는)

Camel에 의해서 활성화되고 통제되는 비 트랜잭션(트랜잭션이 적용되지 않는) 유형이 가장 일반적이다. 트랜잭션(트랜잭션이 적용되는)유형은 J2EE 어플리케이션 서버처럼 지원 시스템에 해 통제된다.

에러가 발생 했을 때 (When does an error happen)

에러가 발생 했을 때 

• Camel내에서 메시지를 라우팅하고 처리 하는 동안 처리되지 않은 Exception이 발생한다.

  그래서 모든 예외를 잡아내고 무엇을 해야 하는지 통제하는 큰 Exception 인터셉터처럼 생각한다. 

비 트랜잭션 (Non transactional : 트랜잭션이 적용되지 않는)

기본적으로 Camel은 비트랜잭션 (트랜잭션이 적용되지 않은) 유형을 사용하고 처리하고 라우팅 하는 동안 에러를 핸들링하는 것 조율한다.

모든 경우에 적용할 단일 에러 핸들링 환경구성이 없기 때문에, 필요로 하는 더 적당한 기본 환경 구성을 바꾸는 것을 고려하여야 한다.

Came 1.x 기본 에러 핸들러 (Camel 1.x default error handler)

Camel 1.x에서 기본적으로 Error Handler 로 전역 Dead Letter Channel 이 설정된다. Dead Letter Channel 은 다음처럼 환경 구성되어있다.:

• 6번까지 재 전송.
• 각각의 재 전송 시도마다 1초의 일시 정지
• 만약 모든 재 전송 시도가 실패하면 데드 레터 큐(dead letter queue)로 exchange를 옮긴다. 
• 기본 데드 레터 큐(dead letter queue)가 ERROR level 에 exchange를 로깅하는 로거이다. 

Camel 2.o 이후 기본 에러 핸들러 (Camel 2.0 onwards default error handler)

Camel 2.0 이후부터는 기본적으로 Error Handler 로 전역 DefaultErrorHandler 설정된다. DefaultErrorHandler는 다음처럼 환경 구성되어 있다. :

• 재 전송 없음
• 데드 레터 큐(dead letter queue) 없음
• 만약 exchage가 실패 하면 Exception을 던지고 RuntimeCamelException에 싸서 원래 요청자에게 다시 전파한다.

Scopes

Camel은 2 Scope를 지원하고 DSL에 의해 결정된다. :

XML DSL을 사용할 때 scope 1은 모든 라우터를 위해 적용한다.  Java DSL을 사용할 때  route 1은 단지 주어진 RouterBuilder 인스턴스을 위해 적용된다. 그래서 만약 복수의 RouterBuilder들을 가지고 있을 때 각각의 라우터 빌더가 자신의 Scope 1가진다.

복수의 RouteBuilder 클래스를 사용할 때 scope가 영향을 받은 것은 Camel 에서 버그가 였다는 것을 신경써라 다음 CAMEL-5456 에서 자세히 보라..

어떻게 데드 레터 채널(Dead Letter Channel) 에러 핸들러가  동작을 하는가?

Camel에서 시작될 때 라우터를 검사하게 되고 라우팅에 에러 핸들링을 짜넣는다. 최대 3까지 지원되는 Scope로, 에러 핸들링이 매우 복잡해 질 수 있다. 그리고 상단에서 에러 핸들을 상속 받고 다른 특정 Exception 유형을 핸들링하기 위한 Exception Clause들을 환경 구성할 수 있다. 그래서 에러의 핸들링 할 때 진보 되었으며 매우 파워풀하다.

단순하게 유지하기 위해 먼저 어떻게 Camel이 재 전송 횟수를 조율하는지 기본 개념을 찾아 보라. 라우터 그래프에서 주어진 노드에 Camel이 현재 라우팅 되고 있는 Exchange를 가로채어서 Error Handler로 감싼다. AOP around 개념처럼 Error Handlere가 차 넣을 수 있다. 만약 Exchange가 아무런 문제 없이 라우팅 될 수 있다면 라우터 그래프에서 다음 노드로 전달 된다. 그러나 만약 Exception이 발생하면 Error Handler라 차 넣고 어떻게 할지 결정한다..

이 설명의 예제 :

이 라우터는 Error Handler가 감시하고 있는 3개 노드를 가지고 있다 (AOP around 방식). 그래서 seda 큐에 요청이 도착했을 때 그것을 소비하고 validateOrder 빈에 보낸다. 이 경우에 validation 빈이 정상 처리 되면 , 다음 노드로 이동한다. 이 경우에 storeOrder 빈이 실패하고 Exception을 발생 시키면 Dead Letter Channel에 의해서 걸려서 다음에 무엇을 할 것인지 결정한다. 다음 중에 하나를 한다.:

• 재전송
• 데드 레터 큐(dead letter queue)로 이동

정책에 환경 구성에 근거 하여 재전송하기 위해 계속 할 것 이다. 기본적으로 Dead Letter Channel은 적어도 1초의 지연 시간을 두고 6회 재 시도를 할 것이다. 그래서 만약 3번째 시도 만에 storeOrder 빈이 성공하면 다음 노드인 confirmOrder 빈에 라우팅이 계속 될 것이다.  이 경우에 모든 재전송이 실패 하면 실패로 간주되고 데드 레터 큐(dead letter queue)로 이동되고 이 exchange의 처리는 멈춘다. 기본적으로 데드 레터 큐(dead letter queue)는 단지 ERROR 로거 이다.

트랜잭션 (Transactional: 트랜잭션이 적용되는)

Camel은 Spring transactions을 활용한다. 보통 JMS 또는 JDBC 기반처럼 제한된 전송 유형의 수만 사용 할 수 있다.  Spring 트랜잭션, J2EE 서버나 Message Broker 같은 아직 필요하다. 

어떻게 동작하는가?

Camel 1.x
Camel은 비 트랜잭션 유형처럼 같이 짜넣는다. 다른 점은 트랜잭션 Exchange를 위해 Error Handler가 차 넣을 수 없다. AOP around가 적용되지 않는다고 말 할 수 있다. Camel은 에러를 핸들링을 조율하기 위해 지원 시스템에 전적으로 의존한다. 그리고 지원시스템이 재전송 할 때 모두 다시 시작하게 된다. 예를 들면 만약 Exchange가 JMS Comsumer에 의해 시작 되었다면 JMS 메시지가 JMS 큐에 롤백되어 다시 시작하게 되고 Camel 다시 JMS 메시지를 재 소비한다.

Camel 2.0
Camel 2.0에서 TransactionErrorHandler가 DefaultErrorHandler 가 했던 것처럼 같은 기반 위에 빌드 될때 권한을 부여 받았다. 이는 트랜잭션 라우터들로 Camel 재전송을 사용하는 것을 허용한다.  Spring transaction manager가 여전히 담당하고 있고 마지막에 동작한다. 그러나 몇몇 로컬 재전송을 하기 위해 Camel을 사용할 수 있다. 예를 들면 FTP 서버에 파일을 올리기 위해 Camel에서 로컬 재전송을 사용할 수 있다. 그래서 양쪽 모두에게 유용하다.    is still in charge and have the last say. But you can use Camel to do some local redelivery, for instance to upload a file to a FTP server, in which Camel can do local redelivery. So this gives you the power from both worlds. 경우에 Camel이 Exchange가 실패 되거나 롤백 되면 재전송 할 수 없다.기본적으로 TransactionErrorHandler 는 어떤 로컬 재전송도 시도하지 않는다 그래서 로컬 재전송을 하기서 예를 들면 최대 재전송에 0보다 큰 숫자를 설정하는 환경 구성을 해야 한다. 

더 자세한 것은 Transactional Client 보라.

참조 (See also)

• Error Handler
• Dead Letter Channel
• Exception Clause
• Transactional Client
• TransactionErrorHandler
• DefaultErrorHandler
• Try Catch Finally
• Failover Load Balancer