JMS 세션은 인바운드 어댑터, 아웃 바운드 어댑터, 오류 채널을 포함하는 흐름 처리와 같은 CachingConnectionfactory

Question

로 구성되어 어떻게 다음과 같은 흐름이 있습니다

1) message-driven-channel-adapter -> 
      1.1) output-channel connected to -> service-activator -> outbound-channel-adapter (for sending response) 
      1.2) error-channel connected to -> exception-type-router 
         1.2.1) message is sent to different queues depending on the exception type using outbound-channel-adapter 

     MessageDrivenChannelAdapter uses DefaultMessageListenrContainer and OutboundAdapter uses JMSTemplate 
     Have used same cachingconnectionfactory for inbound and outbound adapters, 
     set acknowledge="transacted" in messageDrivenChannelAdapter 
     set cacheLevel as CACHE_CONSUMER in DefaultMessageListenerContainer 
     set cacheProducers=true and cacheConsumers=false in CachingConnectionFactory 

내가 그래서 혼란 스러워요 어떻게 JMS 세션/생산자/소비자 이 흐름에서 생성되고 처리됩니다.

1) 인바운드 어댑터에서 사용되는 소비자와 생산자, 아웃 바운드 어댑터 (응답 및 오류 대기열에 사용됨)가 동일한 세션에서 생성되었는지, 즉 스레드에서 사용되는 생성자와 소비자가 동일한 세션에서 생성되는지 여부

2) 그리고 1) 공장에서 cacheConsmers를 false로 설정하고 2) DefaultMessageListenerContainer에서 CACHE_CONSUMER로 캐시 레벨을 설정 한 후에도 cachingconnectionfactory를 사용하는 데 불리한 점이 있는지 확인하고 싶었습니다. 왜냐하면 cachingconnectionfactory를 사용해서는 안된다는 포럼을 읽는 것이 혼란 스럽기 때문입니다.

3) 또한 실행 흐름에 의심의 여지가 있습니다. 흐름에서 서비스 활성기 메서드 실행이 언제 완료됩니까? 메시지가 출력 대기열로 전송 된 후에 만 ​​완료됩니까?

그것은 당신이 변수 동시성을 사용하지 않는 한, 리스너 컨테이너 캐싱 연결 팩토리를 사용하는 확인, 또는 당신이 공장에서 캐싱 소비자를 해제

Answer 1

1. 알려 주시기 바랍니다.
2. 은 캐싱 연결 팩토리를 사용해야합니다. 성능상의 이유로 생성자를 실제로 캐시해야하기 때문입니다. 용기 acknowledgemode는 transacted되면 용기 세션이 나사 결합되어 있고 동일한 연결 팩토리를 사용하도록 구성되어있는 상류 JmsTemplate 의해 사용될

, 아니 비동기 핸드 오프가없는 것이면 (QueueChannel 또는 ExecutorChannel); 기본값 DirectChannel은 컨테이너 스레드의 다운 스트림 끝점을 실행합니다.

아웃 바운드 어댑터로 메시지를 보내기 전에 서비스 활성화 메소드가 호출 ("완료")됩니다.