2016-08-03 1 views
3

IBM JMS 수신 대기 JMS 응용 프로그램을 구현 한 프로젝트에 들어가고 DefaultMessageListenerContainer의 "receiveTimeout"을 이해하는 데 문제가 있습니다.높은 Spring JMS DefaultMessageListenerContainer.receiveTimeout 매개 변수는 무엇을 의미합니까?

인터넷 소스와 비교할 때 내 프로젝트는 "receiveTimeout"매개 변수에 30 초라는 매우 높은 값을 사용한다는 점에서 특별한 의미가 있으며 실제로 이것이 무엇을 의미하는지 알지 못합니다.

나는 "receiveTimeout"매개 변수의 의미를 알아 내려고 노력했으며, Spring 구성 후에는 아래에 나와 있습니다.

참고 : 우리는 대기열에서 실제로는 아주 작은 (약 100kb) 많은 메시지를 읽고 처리하고 있습니다.

우리가 사용하고있는 봄의 구성입니다 :

idleConsumerLimit 특성 :

<bean id="msgListenerContainer" 
     class="org.springframework.jms.listener.DefaultMessageListenerContainer" 
     p:connectionFactory-ref="mqConnectionFactory" 
     p:messageListener-ref="myMessageListener" p:sessionTransacted="true" 
     p:concurrentConsumers="1" p:maxConcurrentConsumers="20" 
     p:receiveTimeout="30000" p:idleTaskExecutionLimit="10" 
     p:idleConsumerLimit="5" /> 

사람이 여기에 다른 매개 변수에 대해 whondering 경우 것은 내가 인터넷을 통해 수집 한 것입니다 주어진 시간에 유휴 상태가 될 수있는 최대 소비자 수인 을 지정하는 데 사용됩니다. 이 제한을 늘리면 호출자가 더 적극적으로 만들어집니다. 이렇게하면 소비자 수를 빠르게 늘릴 수 있습니다.

idleTaskExecutionLimit : 수신 작업의 허용 유휴 실행의 수에 대한 제한. 작업이 메시지를받지 않으면 유휴 리소스 이 일찍 종료되도록 기본값은 1입니다. idleTaskExecutionLimit 속성은 DMLC의 30 초 동안 메시지를 폴링 수신 작업에게 30 초로 설정 작업 1.

receiveTimeout 속성의 기본값 대신 10 번 실행할 수 있도록 10으로 설정 기본값은 1 초입니다.

그래서 이것이 의미 : 무거운 하중 스프링이있는 경우 부하가 내려갑니다 JMS는 즉시이 20 개 소비자 (maxConcurrentConsumers)까지 시작합니다

그리고 여기 내 이해입니다 소비자는 마감 또는 유휴 상태가되기 전에 메시지를 30 초 동안 계속 읽습니다 (receiveTimeout). 그런 다음 5 명의 소비자 (idleConsumerLimit)는 이 종료되기 전에 10 초 (?) (idleTaskExecutionLimit) 동안 계속 유휴 상태가됩니다.

내가 잘못하면 저를 시정하십시오.

한 인터넷 페이지는 내 소비자가 30 초마다 메시지를 읽지 만 "receiveTimeout"의 올바른 해석이라고 생각하지 않습니다.

우리가 현재 갖고있는 한 가지 문제점은 MQ로부터 많은 GET을 읽었지만 실제로 메시지를받지 못한다는 것입니다. 우리가 실제로 2'100 '에 비해 메시지를 읽을 수있는 60,000 GET을 가질 수있는 것처럼, 000 GET은 성공했지만 메시지를 읽지는 않았습니다.

스프링 JMS의 동작을 더 잘 이해할 수있어서 감사드립니다.

답변

1

수신 시간 초과는 더 많은 작업()이있는 경우 브로커 클라이언트에 요청할 때 사용됩니다. 브로커를 폴링하여 클라이언트 라이브러리를 폴링하여 브로커가 더 이상 메시지를 보냈는지 여부를 확인합니다. 메시지 수신 빈도와 관련이 없습니다.

시간 초과가 발생하면 컨테이너는 즉시 을 다시 호출합니다.

받는 시간이 오래 걸리면 컨테이너가 stop() 호출에 덜 응답하게됩니다. 컨테이너는 호출 사이에서만 중지 할 수 있습니다.

+0

30 초 동안 컨테이너에서 실제로 얼마나 자주 'receive()'메소드를 호출합니까? 컨테이너가 언제 'stop()'메서드를 호출합니까? 대기열에 남아있는 메시지가없는 경우 30 초 후 다음에 'receive()'가 표시됩니까? – Invest

+0

컨테이너 스레드는 활성 상태 인 동안 consumer receive() 메서드를 계속 호출합니다 (30 초 동안 차단). 컨테이너는'stop()'을 호출하지 않습니다 - 당신은 그것을 호출 할 수 있습니다. 따라서 더 짧은 시간으로 더 빨리 멈 춥니 다. –

+0

아, 이제 이해합니다. 당신이'stop()'을 적극적으로 호출한다면 실제로 receiveTimeout 매개 변수를 참조하기 전에 30 초가 걸립니다. 고맙습니다! 다시 말하지만 결코'stop()'메서드를 호출하지 않기 때문에 이것은 내 애플리케이션에서 중요하지 않습니다. 또한 프레임 워크가'receive()'메소드를 호출하는 인터뷰를 변경할 수 없다는 느낌을받습니다. 내가 설명했던 이슈가 실제로 경험이 부족하거나 (60'000 메시지를 얻는 동안 2'100'000을 얻음으로써) 프레임 워크의 정상적인 동작이거나 문제인지 확실하지 않습니다. – Invest