Red Hat Summit179.14. JMS를 통한 요청 처리
Camel은 JMS를 통한 요청 처리 지원. 본질적으로 메시지를 JMS 큐에 보낼 때 Exchange의 MEP가 InOut 이어야 합니다.
Camel은 성능 및 클러스터형 환경에 영향을 미치는 JMS를 통해 요청/응답을 구성할 수 있는 다양한 옵션을 제공합니다. 아래 표는 옵션을 요약합니다.
| 옵션 | 성능 | Cluster | 설명 |
|---|---|---|---|
|
| 신속 (Fast) | 제공됨 |
임시 큐는 응답 큐로 사용되며 Camel에서 자동으로 생성됩니다. 이를 사용하려면 replyTo 큐 이름을 지정하지 않습니다. 그리고 선택적으로 |
|
| slow | 제공됨 |
공유 영구 대기열은 응답 대기열로 사용됩니다. 일부 브로커는 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 이상을 사용하는 경우 threads를 사용하는 대신 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);이 경로에서는 5개의 스레드가 있는 스레드 풀을 사용하여 비동기식으로 응답을 라우팅하도록 Camel에 지시합니다.
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);179.14.2. JMS를 통해 요청 및 고정 응답 대기열 사용
Camel 2.9에서 사용 가능
이전 예에서 Camel은 "bar"라는 고정된 응답 대기열이 공유될 것으로 예상하므로 JMSSelector 를 사용하여 필요한 응답 메시지만 사용합니다. 그러나 JMS selectos가 느리기 때문에 이를 수행하는 단점이 있습니다. 또한 응답 대기열의 소비자는 새 JMS 선택기 ID로 업데이트하는 속도가 느립니다. 실제로 receiveTimeout 옵션이 시간 초과된 경우에만 업데이트됩니다. 기본적으로 1초입니다. 따라서 이론적으로는 응답 메시지가 감지되기까지 약 1초까지 걸릴 수 있습니다. 반면 고정 응답 대기열이 Camel 응답 소비자 전용인 경우 JMS 선택기를 사용하지 않도록 할 수 있으므로 더 성능이 저하됩니다. 실제로 임시 큐를 사용하는 것만큼 빠릅니다. 따라서 Camel 2.9 이상에서는 아래 예제와 같이 Camel에 응답 대기열이 배타적임을 알 수 있도록 Exclusive
로 구성할 수 있는 ReplyToType 옵션을 도입했습니다.
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}