Apache ServiceMix

[원문출처] https://camel.apache.org/components/2.x/aws-s3-component.html

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

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

Amazon S3 스토리지 서비스 컴포넌트

Camel 2.8 이후 지원, Both producer 와 consumer 양쪽 모두 지원.

aws-s3://[bucketName|arn][?options]

from("aws-s3://helloBucket?accessKey=yourAccessKey&secretKey=yourSecretKey&prefix=hello.txt")
  .to("file:/var/downloaded");

aws-s3://bucketNameOrArn

AWSCredentials awsCredentials = new BasicAWSCredentials("myAccessKey", "mySecretKey");

ClientConfiguration clientConfiguration = new ClientConfiguration();
clientConfiguration.setProxyHost("http://myProxyHost");
clientConfiguration.setProxyPort(8080);

AmazonS3 client = new AmazonS3Client(awsCredentials, clientConfiguration);

registry.bind("client", client);

from("aws-s3://MyBucket?amazonS3Client=#client&delay=5000&maxMessagesPerPoll=5")
.to("mock:result");

from("file:tmp/test?fileName=test.txt")
     .setHeader(S3Constants.KEY, constant("testFile"))
     .to("aws-s3://mybucket?amazonS3Client=#client&useAwsKMS=true&awsKMSKeyId=3f0637ad-296a-3dfe-a796-e60654fb128c");

  from("direct:start").process(new Processor() {

      @Override
      public void process(Exchange exchange) throws Exception {
          exchange.getIn().setHeader(S3Constants.BUCKET_DESTINATION_NAME, "camelDestinationBucket");
          exchange.getIn().setHeader(S3Constants.KEY, "camelKey");
          exchange.getIn().setHeader(S3Constants.DESTINATION_KEY, "camelDestinationKey");
      }
  })
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=copyObject")
  .to("mock:result");

  from("direct:start").process(new Processor() {

      @Override
      public void process(Exchange exchange) throws Exception {
          exchange.getIn().setHeader(S3Constants.KEY, "camelKey");
      }
  })
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=deleteObject")
  .to("mock:result");

  from("direct:start")
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=listBuckets")
  .to("mock:result");

  from("direct:start")
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=deleteBucket")
  .to("mock:result");

  from("direct:start").process(new Processor() {

      @Override
      public void process(Exchange exchange) throws Exception {
          exchange.getIn().setHeader(S3Constants.KEY, "camelKey");
      }
  })
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=downloadLink")
  .to("mock:result");

  from("direct:start")
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=listObjects")
  .to("mock:result");

  from("direct:start").process(new Processor() {

      @Override
      public void process(Exchange exchange) throws Exception {
          exchange.getIn().setHeader(S3Constants.KEY, "camelKey");
      }
  })
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=getObject")
  .to("mock:result");

  from("direct:start").process(new Processor() {

      @Override
      public void process(Exchange exchange) throws Exception {
          exchange.getIn().setHeader(S3Constants.KEY, "camelKey");
          exchange.getIn().setHeader(S3Constants.RANGE_START, "0");
          exchange.getIn().setHeader(S3Constants.RANGE_END, "9");
      }
  })
  .to("aws-s3://mycamelbucket?amazonS3Client=#amazonS3Client&operation=getObjectRange")
  .to("mock:result");

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-aws-s3</artifactId>
    <version>${camel-version}</version>
</dependency>

<dependency>
  <groupId>org.apache.camel.springboot</groupId>
  <artifactId>camel-aws-s3-starter</artifactId>
  <version>x.x.x</version>
  <!-- use the same version as your Camel core version -->
</dependency>

[원문출처] http://camel.apache.org/defaulterrorhandler.html

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

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

DefaultErrorHandler

Camel 2.0 이후부터 새 기본 에러 핸들로 이다. .

 Dead Letter Channel처럼 같은 힘을 가지고 있다. 그러나 둘 사이의 단지 큰 차이점은 데드 레터 큐(dead letter queue)를 가지지 않는다. 

DefaultErrorHandler 는 Dead Letter Channel에서 환경 구성되었던 것과는 다르게 환경 구성 된다.:

• 재 전송 없음
• 처리 없음
• 데드 레터 큐 (dead letter queue) 없음 (가능하지 않음)

기본적으로, 라우팅 되는 동안 던져진 어떤 exception 호출한 곳에 다시 전파되고 Exchange 는 바로 끝난다. 그러나, 처리된 표시함으로써 주어진 Exception 또는 더 낮은 Exception을 잡아내기 위해 Exception Clause 를 사용 할 수 있다 만약 호출한 곳에 돌려지지 않게 되면 Exchange 가 라우팅 되는 것을 계속 할 수 있다.

예제

아래 라우터에서, 안에 던져진 어떤 exception (예를 들면 validateOrder 빈) Jetty 엔드포인트를 통해서 다시 전파된다. 클라이언트에 HTTO 에러 메시지를 반환하게 될 것이다. 

이 경우에 다르게 확실한 Exception과 라우터를 잡아내기를 원하면 onException 을 추가 할 수 있다. 예를 들면 ValidationException을 잡아 내기 위해 호출한 곳에 고정된 응답을 반환 한다. d return a fixed response to the caller.

validateOrder 빈으로부터 ValidationException 이 발생했을 때, DefaultErrorHandler에 의해 인터셉터되고 onException(ValidationException.class)가 그 에러를 처리 하게 한다. 그래서 Exchange가 onException 라우터에 라우팅되고 handled(true) 를 사용할 때, 원본 Exception은 제거되고 고정된 응답 값으로 jetty 엔드포인트에 돌려줄 원래 호출한 곳에 반환될 메시지를 변형한다.

참고

• Error Handler
• Dead Letter Channel

[원문출처] http://camel.apache.org/dead-letter-channel.html

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

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

데드 레터 채널(Dead Letter Channel)

Camel은 Error Handler인 DeadLetterChannel를 사용하여 EIP patterns으로 부터 Dead Letter Channel을 지원한다.

재전송

임시 정전 또는 데이터베이스 데드락 때문에 메시지를 처리 하는데 실패 하는 원인이 되는 것이 일반적이다.그러나 만약 몇 초의 딜레이로 몇번  재시도 하면 완전히 좋게 될 것이다. 그래서 일반적으로 재전송을 시도하기 전에 얼마나 많이 메시지를 재 전송하기를 원하는지 그리고 얼마나 오래 기다릴 것인지 같은 몇몇 재 전송 정책을 사용하는 것을 원한다.

재 전송 정책(RedeliveryPolicy)은 재전송될 메시지를 어떻게 할 것인지 정의한다. 다음처럼 커스터마이징 할 수 있다.

• 실패로 간주하고 데드 레터 채널로 보내기 전에 얼마나 많이 재 전송되는 것을 시도 하는가
• 초기화 재 전송 타임아웃 
• 지수 백오프 알고리즘을 사용하는지 아닌지 ( 예를 들면, 백오프 멀티플라이어를 사용하여 재시도 시간 간격 증가)
• 충돌을 피하기 위해 타이밍에 약간의 랜덤을 추가할 것인지
• 지연 패턴 (자세한 내용은 아래 참고)
• Camel 2.11: 멈추는 중이거나 셧다운 중일 때 재 전송을 허용할 것인지 아닌지

메시지를를 재 전송하는 모든 시도가 실패하면 메시지는 데드 레터 큐(dead letter queue)로 보내진다.

Exchange가 데드 레터 큐(dead letter queue)에 옮겨지고 처리되는 방법

Dead Letter Channel 에서 처리

모든 재 전송 시도가 실패 했을때 Exchange 가 데드 레터 큐(dead letter queue: dead letter endpoint)로 이동된다. Exchange는 완료되고 뷰의 클라이언트 포인트로부터 처리되게 될 것이다.이와 같이Dead Letter Channel이 Exchange를 처리한다.

예를 들면 다음처럼 데드 레터 채널에 환경 구성한다. :

Fluent Builders를 사용

Spring XML Extensions을 사용

위 Dead Letter Channel은 Exchange.EXCEPTION_CAUGHT 을 키값으로 하는 Exchange의 프로퍼티에 발생된 Exception을 옮김으로써 발생된 Exception(setException(null))을 클리어한다. 그러면 Exchange는 "jms:queue:dead" 에 옮겨지게 되고 클라이언트는 실패를 통보하지 않는다.

Exchange가 데드 레터 큐(dead letter queue)에 옮겨지고  원본 메시지를 사용하는 방법

useOriginalMessage 옵션이 라우팅 하는 동안 잠재적으로 수정된 현재의 메시지 대신에 원본 입력 메시지를 라우팅 하기 위해 사용된다.

예를 들면 다음 라우터를 사용하면 :

이 라우터는 JMS 메시지를 리스닝하고 검증하고 변형하고 처리 한다. 이 Exchange 페이로드가 변형되고 변경되는 동안 이 경우 무언가 잘못되었기 때문에 다른 JMS destination으로 메시지를 옮기기를 원한다. 그러면 우리는 useOriginalMessage 옵션으로 Dead Letter Channel 에 환경 구성할 수 있다.  그러나 destination에 Exchange 가 옮겨졌을 때 이 안에 있는 메시지의 상태를 우리는 알지 못한다. transformOrder 이전에 또는 이후에 에러가 발생했는가? 그래서 jms:queue:order:input 로부터 받은 원본 입력 메시지를 옮기는 것을 원하는지 확인 해야 한다. 그래서 아래처럼 useOriginalMessage 옵션을 활성화함으로써 가능하다.:

그러면 jms:queue:dead에 라우팅된 메시지는 원본 입력 값이다. 만약 수동으로 재 시도 하는 것을 원하면 Input 큐에 JMS 메시지를 옮길 수 있다. 메시지가 아무런 문제가 없다면 메시지는 우리가 수신 받은 원본과 같다.

OnRedelivery

Dead Letter Channel이 재 전송 중 일 때, 매번 재 전송을 시도하기 전에 실행되는 Processor를 환경 구성 하는 것이 가능하다. 재전송 되기 전에 메시지를 바꿀 필요가 있는 상황에서 사용 될 수 있다. 아래 다음 예제를 보라..

재전송 기본 값 (Redelivery default values)

기본적으로 재 전송은 비활성화 되어 있다.

기본 재 전송 정책은 다음 값을 사용 하게 될 것이다. :

• maximumRedeliveries=0
• redeliverDelay=1000L (1 초)
• maximumRedeliveryDelay = 60 * 1000L (60 초)
• 그리고 지수 백오프 알고리즘과 충돌 방지가 꺼져있다.
• retriesExhaustedLogLevel이 LoggingLevel.ERROR로 설정되어 있다.
• retryAttemptedLogLevel이 LoggingLevel.DEBUG로 설정되어 있다.
• Stack traces 가 Camel 2.2 이후부터 소모된 메시지를 위해 로깅된다.
• Camel 2.3 이후 부터 처리된 exception들은 로딩되지 않는다. 
• 기본 에러 핸들러를 위해 logExhaustedMessageHistory가 true이다. 그리고 데드 레터 채널(dead letter channel)을 위해 false 이다.
• Camel 2.17: logExhaustedMessageBody은 기본적으로 민감한 메시지의 Body와 Header 상세 로깅을 피하기 위해  비활성화 되어 있다.만약 이 옵션이 true이면, logExhaustedMessageHistory 옵션도 true여야만 한다..

최대 재 전송 지연 시간은 그 값 보다 지연시간이 더 길지 않다는 것을 보장한다.  기본값 1분. 지수 오프백 알고리즘이 켜져 있다면 발생 할 수 있다.

최대 재 전송은 재 전송을 시도할  수 이다. 기본적으로 Camel은 Exchange 1 + 5회를 처리 하기 위해 시도한다. 일반 시도 1회, 재전송으로 5회 시도한다. 
maximumRedeliveries에 -1과 같은 음수를 설정하면 항상 재 전송한다. (제한 없음).
maximumRedeliveries에 0을 설정하면 어떠한 재 전송 시도도 비활성화 된다.

Camel은 기본적으로 DEBUG 레벨에 전송 실패를 로깅하게 될 것이다. retriesExhaustedLogLevel 또는 를 지정함으로써 변경 할 수 있다. 예지는 ExceptionBuilderWithRetryLoggingLevelSetTest 를 보라 

stack traces의 로깅을 켜고 끌수 있고 만약 꺼져있다면 Camel은 여전히 재 전송 시도를 로깅 하게 될 것이다. 단지 많이 덜 자세한 로그이다.

재 전송 지연 패턴 

지연 패턴은 지연을 위한 범위 패턴을 설정하기 위한 단일 옵션처럼 사용된다. 만약 사용되면 다음 옵션(delay, backOffMultiplier, useExponentialBackOff, useCollisionAvoidance, maximumRedeliveryDelay)은 적용되지 않는다.

다음 구문을 사용하여 범위의 그룹을 설정한다. : limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit N:delay N

각각의 그룹은 콜론으로 구분된 두 값을 가진다.

• limit = 상위 제한 limit
• delay = 밀리세컨드 지연시간
  그리고 그룹은 다시 세비 콜론으로 구분된다.
  다음 그룹이 이전 그룹보다 더 높은 제한을 가져야 하는 것은 경험 법칙이다.

다음 예로 명확하게 해보자:
delayPattern=5:1000;10:5000;20:20000

3개 그룹들이 주어졌다.:

• 5:1000
• 10:5000
• 20:20000

재 전송 시도를 위한 3개의 지연시간의 결과:

• 재 전송 시도 1..4회차 = 0 millis (첫번째 그룹이 5부터 시작 하므로)
• 재 전송 시도 5..9회차 = 1000 millis (첫번째 그룹)
• 재 전송 시도 10..19회차 = 5000 millis (두번째 그룹)
• 재 전송 시도 20..회차 이상 = 20000 millis (마지막 그룹)

주의 : 첫번째 재 전송 시도는 1 이다 첫번째 그룹은 1부터 시작하거나 더 커야 한다. 

제한이 1부터 시작하는 그룹으로 지연 시간이 시작 될 수 있다. : delayPattern=1:1000;5:5000

• 재 전송 시도 1..4회차 = 1000 millis (첫번째 그룹)
• 재 전송 시도 5..회차 이상 = 5000 millis (마지막 그룹)

다음 지연시간이 이전 보다 높아야 할 필요는 없다. 원하는 지연 시간 값을 사용할 수있다. 예를 들면  delayPattern=1:5000;3:1000, 5초 단위로 지연 시간을 가지고 시작해서 마지막에는 1초 단위로 감소한다. 

재 전송 헤더 (Redelivery header)

메시지가 재 전송 될 때, DeadLetterChannel은 얼마나 많은 재 전송 시도를 하였는지 표시하기 위해 메시지에 사용자 정의 헤더를 추가 한다. 
Camel 2.6 이전 버전: 헤더는 Exchange.REDELIVERY_COUNTER에 정의된 CamelRedeliveryCounter이다.

Camel 2.6 이후 부터: 헤더는 최대 전송을 설정 하는 것을 포함하는 Exchange.REDELIVERY_MAX_COUNTER에 정의된 CamelRedeliveryMaxCounter이다. 만약 retryWhile 을 사용하거나 또는 환경 구성된 최대 재 전송에 제한이 없으면 이 헤더 값은 존재 하지 않는다. 

그리고 불린 값으로 재 전송 될지 아닌지를 판단. (첫번째 시도에서)
헤더 값 CamelRedelivered은 불린 값으 포함한다. 만약 재 전송 되거나 아니거나 이면 Exchange.REDELIVERED 에 정의 되어 있다. 

exchange로 부터 동적으로 계산된 지연 시간.
Camel 2.9 또는 2.8.2에서 : 헤더 값 CamelRedeliveryDelay은 Exchange.REDELIVERY_DELAY에 정의 되어 있고 이 헤더 값이 없으면 일반 재 전송 률이 적용된다..

어느 엔드포인트가 실패인가?

Camel 2.1부터 가능 한 것

Camel이 메시지를 라우터 할 때 마지막 엔드포인트를 포함하는 속성을 가진 Exchange 장식한다. Camel은 Exchange 를 보낸다. :

Exchange.TO_ENDPOINT 는 CamelToEndpoint 상수 값을 가진다. .

이 정보는 Camel이 어떤 엔드 포인트에 메시지를 보낼때 업데이트 된다. 그래서 만약 존재 하면 카멜이 Exchange를 보낸 마지막 엔드 포인트 이다. 

예를 들면 주어진 Endpoint 에 Exchange를 처리하거나 그 메시지가 데드 레터 큐(dead letter queue)로 옮겨 질 때  Camel은 또한 마지막 엔드포인트를 포함하는 또 다른 프로퍼티를 Exchange를 장식한다.:

Exchange.FAILURE_ENDPOINT 는 CamelFailureEndpoint 상수 값을 가진다..

예를 들면 데드 레터 큐(dead letter queue)에 정보를 패치하고 에러 리포팅을 위해 사용하는 것을 허용한다. 

만약 Camel 라우터가 동적 Recipient List  같은 동적 비트이면 실패한 엔드포인트를 알 수 있다.

주의: 그 정보들은 주어진 엔드포인트에 의해 심지어 메시지가 성공적으로 처리되더라도  Exchange에 유지된다. 그리고 예를 들면 로컬 Bean 에서 마지막 실패는 대신 처리 된다.  그래서 정확한 에러를 돕는 힌트를 조심해야 한다. 

이제 위 라우터가 foo 빈에서 실패가 발생하는 것을 가정한다. 그러면 Exchange.TO_ENDPOINT 와 Exchange.FAILURE_ENDPOINT가 여전히 http://someserver/somepath 값을 포함하게 될 것이다 .

OnPrepareFailure

Camel 2.16부터 가능

exchange가 데드 레터 큐(dead letter queue)에 보내지기 전에, you can use onPrepare to allow a custom Processor to prepare the exchange를 준비하기 위해 Exchange가 왜 실패 했는지 정보를 추가 하는 것 같은 사용자 정의 Processor 를 허용하기 위해  onPrepare 를 사용 할 수 있다.  예를 들면 다음 프로세서는 Exception 메시지를 헤더에 추가한다.

그리고 다음처럼 프로세서를 사용하기 위해 에러 핸들러를 환경 구성한다. :

XML DSL으로 환경 구성하는 것은 다음 보여지는 것과 같다. :

The onPrepare is also available using the default error handler.

Which route failed

Available as of Camel 2.10.4/2.11

When Camel error handler handles an error such as Dead Letter Channel or using Exception Clause with handled=true, then Camel will decorate
the Exchange with the route id where the error occurred.

The Exchange.FAILURE_ROUTE_ID have the constant value CamelFailureRouteId.

This allows for example you to fetch this information in your dead letter queue and use that for error reporting.

stopping/shutdown 되는 동안 재 전송이 허용될 때 컨트롤

Camel 2.11이후부터 가능

Camel 2.10 이전은, Camel 라우터가 멈추거나 Camel이 셧다운 되는 동안 재 전송을 수행하게 될 것이다. 이것이 Camel 2.10는 적극적으로 셧다운되는동안은 재 전송 시도를 수행하지 않는 것 처럼 조금 개선 되었다. (예를 들면 Graceful Shutdown 동안 그리고 타임아웃을 입력하면). Camel 2.11 이후부터 재 전송을 허용하는지 아닌지 컨트롤 하기 위해 사용할 수 있는 새 옵션 allowRedeliveryWhileStopping이 있다.; 어진행중엔 어떠한 재 전송도 여전히 실행 되는 것에 주의하라 이 옵션은 단지 route가 멈추는 중이거나 / Camel이 shutdown이 실행된 이후에  어떤 재 전송이 실행되는 것은 허용하지 않는다. 만약 재 전송이 허용되지 않는다면, Exchange 에 RejectedExcutionException 설정 될 것이고  Exchange 정지 처리를 한다. 그 의미는 모든 Comsumer는 RejectedExecutionException 실패로 Exchange 를 보게 될 것이다.   

역주) Route가 정지되거나 Camel이 셧다운되면 진행중인 프로세스는 모드 Exchange RejectedExcutionException 으로 오류 처리 한 후에 정지 및 셧다운이 수행된다.

이전 처럼 이전 버전과 호환 가능하게 되는 것은 기본 값은 true이다 to be backwards compatible as before. 예를 들면 다음 예제는 어떻게  Java DSL 과 XML DSL를 사용 하는지를 방법을 보여 준다.

그리고 XML DSL로  사용하는 샘플

샘플

다음 예제는 DSL을 사용하여 Dead Letter Channel을  어떻게 환경 구성하는지를 보여 준다. 

이 예제로 RedeliveryPolicy을 환경 구성할 수 있다.

어떻게 재 전송 전에 Exchange 를 변경 할 수 있는가?

Dead Letter Channel 에서 직접적으로 각각의 재 전송 시도 이전에 수행되어야 할 Processor 를 설정 하는 것을 지원한다. 

Dead Letter Channel이 재 전송이 수행 될 때, 모든 재 전송 시도 이전에 단지 실행할 Processor 를 환경 구성하는 것이 가능하다. 재 전송 이전에 메시지를 변경할 필요가 있을 때 어느 상황에서나 사용 될 수 있다. 

여기 각각의 재 전송 이전에 수행될 MyRedeliveryProcessor 를 사용하기 위해 Dead Letter Channel을 환경 구성한다.

그리고 메시지를 변경할 곳에서 MyRedeliveryProcessor 이다..

무슨 이유로 데드 레터 채널이 호출 되었는지 어떻게  로그 기록 할 수 있나 ?

종종 무엇이 잘못되어 데드 레터 채널이 발생되어 갔었는지 알 필요가 있다. 그러나 이 목적을 로깅 하는 것을 제공하지는 않는다. 그래서 Dead Letter Channel의 엔드포인트는 자신의 엔드 포인트에 설정 될 필요가 있다. (direct:deadLetterChannel 처럼). 우리는 실패한 Exchange 를 옮기기를 원하는 곳 앞에 Exchange 를 받아 들이고 Exception을 로그 기록하기 위해 라우터를 작성한다. (예를 들면 DLQ 큐라 할지라도).  http://stackoverflow.com/questions/13711462/logging-camel-exceptions-and-sending-to-the-dead-letter-channel를 보라

이패턴 사용하기 

만약 EIP 패턴을 사용하는 것을 원하면 Getting Started를 읽어라. 아마 특별히 Endpoint 와 URIs 상세한 묘사하는 유용한 아키텍처를 찾을 수 있을 것이다.  그러면 당신은 패턴을 찾는 것을 시도하기 전에 이 예제(Examples )를 시도할 수 있습니다. 

• Error Handler
• Exception Clause

[원문출처] 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