Red Hat Summit178.14. JMS를 통한 요청
Camel은 Request Reply over JMS를 지원합니다. JMS 대기열에 메시지를 보낼 때 Exchange의 MEP는 InOut 이어야 합니다.
Camel은 성능 및 클러스터 환경에 영향을 주는 JMS를 통해 요청/응답을 구성할 수 있는 다양한 옵션을 제공합니다. 아래 표에서는 옵션을 요약합니다.
| 옵션 | 성능 | Cluster | 설명 |
|---|---|---|---|
|
| 신속 (Fast) | 제공됨 |
임시 대기열은 응답 대기열로 사용되며 Camel에 의해 자동으로 생성됩니다. 이 기능을 사용하려면 replyTo 대기열 이름을 지정하지 않습니다. 임시 큐가 사용 중임을 알 수 있도록 |
|
| 느린 | 제공됨 |
공유 영구 대기열은 응답 대기열로 사용됩니다. 일부 브로커는 사전에 큐를 생성해야 하지만 일부 브로커는 Apache ActiveMQ와 같이 즉시 생성할 수 있습니다. 이를 사용하려면 replyTo 대기열 이름을 지정해야 합니다. 선택적으로 |
|
| 신속 (Fast) | 아니요(예:) |
전용 영구 큐는 응답 큐로 사용됩니다. 일부 브로커는 사전에 큐를 생성해야 하지만 일부 브로커는 Apache ActiveMQ와 같이 즉시 생성할 수 있습니다. 이를 사용하려면 replyTo 대기열 이름을 지정해야 합니다. 또한 |
|
| 신속 (Fast) | 제공됨 |
Camel 2.10.3: 사용 중인 동시 메시지 리스너를 사용하여 응답 메시지를 동시에 처리할 수 있습니다. |
|
| 신속 (Fast) | 제공됨 |
Camel 2.10.3: 사용 중인 동시 메시지 리스너를 사용하여 응답 메시지를 동시에 처리할 수 있습니다. |
JmsProducer 는 InOut 을 감지하고 사용할 응답 대상과 함께 JMSReplyTo 헤더를 제공합니다. 기본적으로 Camel은 임시 대기열을 사용하지만 끝점에서 replyTo 옵션을 사용하여 고정된 응답 대기열을 지정할 수 있습니다(정의된 응답 대기열에 대한 아래 참조).
Camel은 응답 대기열에서 수신 대기하는 소비자를 자동 설정하므로 아무 작업도 수행하지 않아야 합니다.
이 소비자는 응답을 수신하는 Spring DefaultMessageListenerContainer 입니다. 그러나 동시 소비자는 1명으로 고정되어 있습니다.
즉, 응답을 처리할 스레드는 1개뿐이므로 응답이 순서대로 처리됩니다. 응답을 더 빠르게 처리하려면 동시성을 사용해야 합니다. concurrentConsumer 옵션은 사용하지 않습니다. 아래 경로에 표시된 대로 Camel DSL의 스레드 를 사용해야 합니다.
스레드를 사용하는 대신 Camel 2.10.3 이상을 사용하는 경우 concurrentConsumers 옵션을 사용합니다. 아래를 참조하십시오.
from(xxx)
.inOut().to("activemq:queue:foo")
.threads(5)
.to(yyy)
.to(zzz);
from(xxx)
.inOut().to("activemq:queue:foo")
.threads(5)
.to(yyy)
.to(zzz);이 경로에서는 Camel에 스레드가 5개인 스레드 풀을 사용하여 응답이 비동기식으로 라우팅하도록 지시합니다.
Camel 2.10.3 이상에서는 concurrentConsumers 및 maxConcurrentConsumers 옵션을 사용하여 동시 스레드를 사용하도록 리스너를 구성할 수 있습니다. 이를 통해 다음과 같이 Camel에서 이를 보다 쉽게 구성할 수 있습니다.
from(xxx)
.inOut().to("activemq:queue:foo?concurrentConsumers=5")
.to(yyy)
.to(zzz);
from(xxx)
.inOut().to("activemq:queue:foo?concurrentConsumers=5")
.to(yyy)
.to(zzz);178.14.2. JMS를 통한 요청 및 전용 고정 응답 대기열 사용
Camel 2.9에서 사용 가능
이전 예에서 Camel은 "bar"라는 고정된 응답 대기열이 공유되므로 JMSSelector 를 사용하여 예상되는 응답 메시지만 사용합니다. 그러나 JMS selectos가 느리기 때문에 이러한 문제가 발생할 수 있습니다. 또한 응답 대기열의 소비자가 새 JMS 선택기 ID로 업데이트하는 속도가 느립니다. 실제로 receiveTimeout 옵션 시간이 초과되는 경우에만 업데이트되며 기본적으로 1초입니다. 따라서 이론적으로는 응답 메시지가 감지되는 약 1초가 걸릴 수 있습니다. 반면 고정 응답 대기열이 Camel 응답 사용자에게 배타적인 경우 JMS 선택기 사용을 방지할 수 있으므로 더 성능이 향상됩니다. 임시 큐를 사용하는 것처럼 속도가 빠릅니다. 따라서 Camel 2.9 이상에서는
를 제외하도록 구성할 수 있는 ReplyToType 옵션을 도입하여 Camel에 아래 예와 같이 응답 대기열이 배타적임을 알릴 수 있습니다.
from(xxx)
.inOut().to("activemq:queue:foo?replyTo=bar&replyToType=Exclusive")
.to(yyy)
from(xxx)
.inOut().to("activemq:queue:foo?replyTo=bar&replyToType=Exclusive")
.to(yyy)큐는 각 끝점 및 모든 끝점에 대해 배타적이어야 합니다. 두 개의 경로가 있는 경우 다음 예와 같이 각각 고유한 응답 큐가 필요합니다.
클러스터된 환경에서 실행되는 경우에도 마찬가지입니다. 클러스터의 각 노드는 고유한 응답 대기열 이름을 사용해야 합니다. 그렇지 않으면 클러스터의 각 노드는 다른 노드에서 응답으로 의도된 메시지를 선택할 수 있습니다. 클러스터된 환경의 경우 공유 응답 대기열을 대신 사용하는 것이 좋습니다.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}