[원문 출처] http://activemq.apache.org/vm-transport-reference.html


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

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





VM 전송

VM 전송은 클라이언크가 네트워크 커넥터의 오버헤드 없이 VM 내부에 다른 곳에 접속 하는 것을 허용한다. 이 커넥션은 소켓 커넥션이 사용되지 않는다. 그러나 고성능의 내장된 메시징 시스템을 사용 가능하게 직접 메서드 호출을 사용한다. .

VM 커넥션을 사용하기 위한 첫번째 클라이언트는 내장된 브로커를 구동하게 된다.  그 뒤의 클라이언트 커넥션은 같은 브로커에 접속한다. 일단 브로커에 접속하기 위한 모든 VM 커넥션이 모두 닫히게 되면, 내장된 브로커는 자동적으로 셧다운 된다.


심플 브로커 환경 구성 구문

VM 커넥션을 위한 일반적인 구문인 simple 이고, 단지 제한된 내장된 브로커의 환경 구성을 제공한다. 


vm://brokerName?transportOptions


만약 이미 인스턴스화된 브로커에 접속을 원하면, 내장된 브로커(예를 들면. Apache ServiceMix 같은 경우에 ) brokerName에  이미 실행중인 브로커의 brokerName 과 일치하는 것이 사용 된 vm://brokerName URI를 사용하는 것을  보장한다. 

전송 옵션

옵션 명

기본값

상세 설명

marshal

false

만약 true 이면, 각각의 명령어가 WireFormat을 사용하여 강제로 marshalled 와 unmarshalled 된 VM 전송 통해 보낸다. 

wireFormat

default

사용할  WireFormat 의 이름

wireFormat.*

 

wireFormat을 환경 구성하기 위해 사용되는 이 접두사로 된 모든 프로퍼티.

create

true

만약 브로커가 존재 하지 않는다면 요청에 의해 브로커를 생성하게 될 것 인지 여부

waitForStart

-1

만약 0보다 크면, 브로커를 시작하기 위해 기다리는 밀리세컨드 타임아웃을 나타낸다. -1 과 0 은 기다리지 않는다는 것을 의미한다. 단지 ActiveMQ 5.2+ 에서 지원된다.

broker.*

 

브로커를 환경 구성하기 위해 사용되는 이 접두어를 사용하는 모든프로퍼티 . 더 많은 정보는 Wire Formats 환경구성하기 를 보라.

예제 URI
vm://broker1?marshal=false&broker.persistent=false

내장된 브로커 주의

만약 VM 전송을 사용하고 명시적으로 내장된 브로커 를 환경구성하는 것을 원하면, 브로커를 시작하기 전에 JMS 커넥션을 생성할 기회가 있다. 만약 VM 전송을 사용하고 이미 환경 구성된 브로커가 없다면, 현재 ActiveMQ는 브로커를 자동생성하게 될 것이다. (ActiveMQ 5.2 이상에서,  커넥션 URI를 사용을 위해 waitForStart 와 create=false 옵션을 사용하는 것이 가능하다.)

만약 스프링을 사용한다면 이 문제를 해결하기 위해,  내장된 브로커에서 이 문제가 발생하는 것을 피하기 위해 JMS ConnectionFactory가 depends-on 속성을 사용해야 할지 모른다. 

예를 들면.

<bean id="broker" class="org.apache.activemq.xbean.BrokerFactoryBean">
    <property name="config" value="classpath:org/apache/activemq/xbean/activemq.xml" />
    <property name="start" value="true" />
  </bean>
 
  <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory" depends-on="broker">
    <property name="brokerURL" value="vm://localhost"/>
  </bean>

어드벤스드 브로커 환경 구성 구문

VM 커넥션을 위한 어드벤스드 구문이다. Broker 브로커 환경  구성 URI를 사용하여 좀더 광범위하게 브로커를 환경 구성하는 것을 허용한다. 

vm:(broker:(tcp://localhost)?brokerOptions)?transportOptions

또는 
vm:broker:(tcp://localhost)?brokerOptions

전송 옵션 

옵션명

기본값

상세 설명

marshal

 false

만약 true 이면, 각각의 명령어가 WireFormat을 사용하여 강제로 marshalled 와 unmarshalled 된 VM 전송 통해 보낸다. 

wireFormat

default

사용할  WireFormat 의 이름

wireFormat.*

 

WireFormat을 환경 구성하기 위해 사용되는 이 접두사를 사용하는 모든 프로퍼티

VM 전송을 사용을 최적화 하는 더 많은 옵션이 있다.

예제 URI
vm:(broker:(tcp://localhost:6000)?persistent=false)?marshal=false

외부 환경 구성 파일을 사용하여 내장된 브로커 환경 구성하기 

 VM 전송과 외부 환경 구성 파일을 사용하여 (i.e. activemq.xml) 내장된 브로커를 시작하기 위해, 다음 URI를 사용하라:


vm://localhost?brokerConfig=xbean:activemq.xml


[원문출처] 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 을 보라.

예외 절(Exception Clause)

Error Handler 가 Exception Clause을 결합하여 사용하는 것은 매우 파워풀한 결합이다. 최종사용자(end-users)들이 에러를 핸들링하는 전략에서 이것을 조합하는 것을 권장한다. 샘플과 Exception Clause를 보라.

try ... catch ... finally 사용하기

라우터에서 직접 사용할 수 있는 DSL 처럼 에러 핸들링과 관련된 것이 Try Catch Finally 이다. 기본적으로 자바에서 try catch finally 를 모방이지만 더 파워풀하다.

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

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

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

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

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

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

DefaultErrorHandler

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

Dead Letter Channel

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

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

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // using dead letter channel with a seda queue for errors
        errorHandler(deadLetterChannel("seda:errors"));
 
        // here is our route
        from("seda:a").to("seda:b");
    }
};

또는 in Spring DSL 에서

<bean id="deadLetterErrorHandler" class="org.apache.camel.builder.DeadLetterChannelBuilder">
  <property name="deadLetterUri" value="log:dead"/>
</bean>
 
<camelContext errorHandlerRef="deadLetterErrorHandler" xmlns="http://camel.apache.org/schema/spring">
  ...
</camelContext>

또는 Camel 2.3.0 이후 부터 또한

<camel:errorHandler id="deadLetterErrorHandler" type="DeadLetterChannel" deadLetterUri="log:dead">
 
<camel:camelContext errorHandlerRef="deadLetterErrorHandler">
  ...
</camel:camelContext>

Logging Error Handler

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


errorHandler(loggingErrorHandler("mylogger.name").level(LoggingLevel.INFO));

또는 Spring DSL 에서

<bean id="loggingErrorHandler" class="org.apache.camel.builder.LoggingErrorHandler">
  <property name="logName" value="mylogger.name"/>
  <property name="level" value="DEBUG"/>
</bean>
 
<camelContext errorHandlerRef="loggingErrorHandler" xmlns="http://camel.apache.org/schema/spring">
  ...
</camelContext>

또는 Camel 2.3.0 이후 부터 또한

<camel:errorHandler id="loggingErrorHandler" type="LoggingErrorHandler" logName="mylogger.name" level="DEBUG"/>
 
<camel:camelContext errorHandlerRef="loggingErrorHandler">
  ...
</camel:camelContext>

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


from("seda:a").errorHandler(loggingErrorHandler("mylogger.name").level(LoggingLevel.DEBUG)).to("seda:b");

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

No Error Handler

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


errorHandler(noErrorHandler());

또는 Spring DSL에서

<bean id="noErrorHandler" class="org.apache.camel.builder.NoErrorHandlerBuilder"/>
 
<camelContext errorHandlerRef="noErrorHandler" xmlns="http://camel.apache.org/schema/spring">
  ...
</camelContext>

또는 Camel 2.3.0 이후 부터 또한

<camel:errorHandler id="noErrorHandler" type="NoErrorHandler"/>
 
<camel:camelContext errorHandlerRef="noErrorHandler">
  ...
</camel:camelContext>

TransactionErrorHandler

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

만약 트랜잭션을 지원하는 DSL을 사용하여 트랜잭션으로 라우터를 만들면 Camel은 자동적으로 TransactionErrorHandler를 사용하게 될 것이다. 글로벌 또는 라우터당 환경 구성된 에러 핸들러를 찾으려고 시도하게 될 것이고 만약 TransactionErrorHandlerBuilder 인스턴스이면 그걸 사용하게 될 것이다. 만약 Camel에서 찾지 못하면 기본 에러 핸들러를 우선하는 임시 TransactionErrorHandler가 자동으로 생성되게 될 것이다. 환경 구성을 통한 규칙이다.

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

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

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

Scopes

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

  • global
  • route 당

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

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // logging error handler를 사용
        errorHandler(loggingErrorHandler("com.mycompany.foo"));
 
        // 여기서 표준 라우터이다.
        from("seda:a").to("seda:b");
    }
};

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

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // 이 라우터는 중첩된 로깅 에러 핸들러를 사용하고 있다.
        from("seda:a")
            // 여기에 logging error handler를 환경 구성한다..
            .errorHandler(loggingErrorHandler("com.mycompany.foo"))
            // 그리고 여기로 라우팅을 계속 한다.
            .to("seda:b");
 
        // 이 라우터는 기본 에러 핸들러 (DeadLetterChannel)을 사용하게 될 것이다.
        from("seda:b").to("seda:c");
    }
};

Spring 기반의 환경 구성

Java DSL 대 Spring DSL

에러 핸들러는 Java DSL과 Spring DSL 에서 크게 다르게 환경 설정 된다. Jaba DSL은 능숙한 빌더를 사용하는 반면에 Spring DSL은 표준 Spring Bean 환경에 더 의존한다.

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

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

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

에러 핸들러 계층(Error Handler Hierarchy)

에러 핸들러는 상속 된다. 그래서 만약 당신이 글로벌 에러 핸들러를 설정하면 어디서든지 사용 가능하다. 그러나 라우터에서 또는 다른 에러 핸들러를 사용하여 오버라이딩 할 수 있다. 

Spring 기반 환경 구성 예제

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

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

  <camelContext xmlns="http://camel.apache.org/schema/spring">
      <template id="myTemplate"/>
<!-- DeadLetterChannel에 errorHandlerRef 를 설정, 단지 이 라우터를 위해서만 적용된다. -->
      <route errorHandlerRef="myDeadLetterErrorHandler">
          <from uri="direct:in"/>
          <process ref="myFailureProcessor"/>
          <to uri="mock:result"/>
      </route>
  </camelContext>

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

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

<!-- 여기 DeadLetterChannel을 환경 구성한다. -->
<bean id="myDeadLetterErrorHandler" class="org.apache.camel.builder.DeadLetterChannelBuilder">
     <!-- 재 전송 실패 시 exchange가 mock:dead 에 라우팅 된다. -->
       <property name="deadLetterUri" value="mock:dead"/>
     <!-- 사용할 재전송 정책을 참조한다. -->
       <property name="redeliveryPolicy" ref="myRedeliveryPolicyConfig"/>
</bean>
 
   <!-- 여기 재 전송 설정을 설정한다. -->
<bean id="myRedeliveryPolicyConfig" class="org.apache.camel.processor.RedeliveryPolicy">
     <!-- 최대 3번 재전송 시도하고 전송 실패 시 mock:dead endpoint에 라우팅 된다. -->
       <property name="maximumRedeliveries" value="3"/>
     <!-- 재전송 전에 delay 250ms초 지연 -->
       <property name="redeliveryDelay" value="250"/>
</bean>

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

<errorHandler id="loggingErrorHandler" type="LoggingErrorHandler" logName="foo" level="INFO"
 
<!-- 만약 유형 속성이 지정되지 않으면 유형 값은 DefaultErrorHandler가 설정되게 될 것이다. -->
<errorHandler id="errorHandler" xmlns="http://camel.apache.org/schema/spring"/>
 
<!-- 에러 핸들러 안쪽에 재전송 정책(redeliveryPolicy )을 정의 할 수 있다. -->
<camel:errorHandler id="defaultErrorHandler" type="DefaultErrorHandler">
    <camel:redeliveryPolicy maximumRedeliveries="2" redeliveryDelay="0" logStackTrace="false"/>
</camel:errorHandler>
 
<camel:errorHandler id="deadLetterErrorHandler" type="DeadLetterChannel" deadLetterUri="log:dead">
    <camel:redeliveryPolicy maximumRedeliveries="2" 
redeliveryDelay="1000" 
logHandled="true" 
asyncDelayedRedelivery="true"/>
</camel:errorHandler>
 
<bean id="myErrorProcessor" class="org.apache.camel.spring.handler.MyErrorProcessor"/>
 
<!-- TX 에러 핸들러는 템플릿을 사용하여 환경 구성 될 수 있다. -->
<camel:errorHandler id="transactionErrorHandler" type="TransactionErrorHandler"
                    transactionTemplateRef="PROPAGATION_REQUIRED" onRedeliveryRef="myErrorProcessor"/>
 
<!-- 또는 트랜잭션 관리 를 사용한다. -->
<camel:errorHandler id="txEH" type="TransactionErrorHandler" transactionManagerRef="txManager"/>
 
<!-- camelContext 안쪽에 에러 핸들러를 정의 할 수 있다. -->
<camelContext errorHandlerRef="noErrorHandler" xmlns="http://camel.apache.org/schema/spring">
    <errorHandler id="noErrorHandler" type="NoErrorHandler"/>
</camelContext>

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

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

See also


+ Recent posts