WebSphere MQ 큐에서 소비하는 동안 Spring JMS 제한 시간 만료

Question

QUEUE1에서 비동기 적으로 "트리거"를 수신하는 Spring JMS 기반 클라이언트가 있고 다른 큐 QUEUE2에서 사용할 준비가 된 메시지가 있음을 나타냅니다.

<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate"> 
     <constructor-arg ref="gpyConnectionFactory" /> 
     <property name="destinationResolver" ref="jndiDestinationResolver" /> 
     <property name="receiveTimeout" value="100" /> 
    </bean> 

주의 작은 receiveTimeout을 다음과 같이 QUEUE2에

소비는 구성이 JmsTemplate 클래스로 이루어집니다. 이 값은이 응용 프로그램을 담당하기 전에 이미 적용되었습니다.
지금, 나는 그것이 가능성이 제한 시간이 만료 그래서 가끔, 특히 QUEUE2는,

에 NULL 개체를 검색

jmsTemplate.receiveSelectedAndConvert(destinationName, mqSelector); 

에 상대적으로 큰 메시지 전화가 포함 된 경우 것으로 나타났습니다!

필자가 아는 한 JMS 사양 (올바른 메일 일 경우)으로 대기열에서 메시지를 사용할 수없는 경우에만 시간 초과가 만료됩니다. 현재의 시나리오는 메시지 크기와 그 큐의 메시지가 있다는 사실 때문에 소비자가 큰 메시지 전체를 읽을 시간이 없기 때문에 타임 아웃이 만료된다고 생각합니다. 그게 전부 가능한가?

제공자는 WebSphere MQ입니다.

확실히 높은 시간 제한 값을 설정합니다.

Answer 1

시간 초과는 Spring에 의해 처리되지 않고 벤더 JMS 라이브러리 ... return consumer.receive(timeout)에서 처리됩니다.

메시지가 대기열에 도착하면 브로커가 메시지를 "푸시"하지만 큰 메시지를 전송하는 데 제한된 시간이 걸리므로 consumer.receive() 작업이 시간 초과 (반복적으로) 될 수 있습니다. 메시지가 완전히 전송 될 때까지

처리를 실제로하는 것은 공급 업체 코드에 달렸지 만 메시지가 전송되는 과정에서 수신을 차단하는 것은 의심 스럽습니다.

따라서 하나의 대기열에 메시지를 넣는 것은 다른 대기열에서 메시지를 사용할 수 있다는 것을 알리는 신뢰할만한 방법이 아닙니다.

실제 대기열에서 수신하는 것 (또는 JmsTemplate 대신 메시지 구동 방식을 사용하는 것)을 고려하십시오.