JMSXDeliveryCount가 증가한 경우

Question

WebSphere MQ에서 JMSXDeliveryCount이 증가하는 조건은 무엇입니까? 일어날 수있는 모든 시나리오가 필요합니다.

Answer 1

고맙습니다. 답장 양식 웹을 가져 와서 여기에 붙여 넣어 다른 사람에게 도움이 될 수 있도록하십시오.

메시지가 사용자에게 전달 될 수있는 상황은 세션의 확인 모드에 따라 달라집니다 메시지를 소비자에게 전달했다 AUTO_ACKNOWLEDGE 또는 DUPS_OK_ACKNOWLEDGE 확인 모드를 선택

• 비 거래 세션을 할 때 응용 프로그램의 onMessage() 메서드는 예외를 throw합니다. 클라이언트 런타임에서 예외를 catch 한 다음 onMessage()를 다시 호출합니다. 예외는 캐치되어 Connection의 ExceptionListener에보고됩니다. 재전송 횟수를 제한하면 재전송 횟수가 제한됩니다. 아래 참고 사항을 참조하십시오.

• SINGLE_MESSAGE_ACKNOWLEDGE 또는 CLIENT_ACKNOWLEDGE 확인 모드를 선택하는 트랜잭션이 아닌 세션은 응용 프로그램이 Session.recover()를 호출 할 때 메시지가 다시 전달됩니다.

• TRANSACTED 확인 모드에서는 응용 프로그램이 트랜잭션을 롤백 할 때 메시지가 다시 전달됩니다.

응용 프로그램이 반복적으로 응용 프로그램이 실패하게하는 메시지를받는 루프를 반복적으로 수신 한 다음 동일한 메시지가 반복해서 전달됩니다. 무한 재 전달 루프를 때때로 "독이있는 메시지 시나리오"라고합니다.

• 재 배달 시도를 제한하려는 지점 간 (큐 기반) 소비자 클라이언트는 ConnectionFactory에 매개 변수를 지정하여 소비자에게 보내는 메시지 배달 횟수를 제한 할 수 있습니다. . 이것은 progress.message.jclient.ConnectionFactory.setMaxDeliveryCount (java.lang.Integer value) 메소드를 사용하여 수행됩니다. 값 0 (기본값)은 제한 없음을 나타냅니다.

재전송 제한을 초과했지만 확인되지 않은 메시지는 메시지에 지정된 등록 정보에 따라 처리되거나 폐기됩니다.

메시지 속성이 JMS_SonicMQ_preserveUndelivered true로 설정하면, 메시지가 SonicMQ.DeadMessage 큐 (또는 JMS_SonicMQ_destinationUndelivered 속성에 의해 지정된 대체 대상)에 배치되며, 메시지 속성 JMS_SonicMQ_undeliveredReasonCode이 오류 코드 진행으로 설정됩니다 .message.jclient.Constants.UNDELIVERED_DELIVERY_LIMIT_EXCEEDED. 'preserveUndelivered'속성을 설정하지 않으면 메시지가 삭제됩니다.

• 또는 (예 : 펍 서브 주제 기반 클라이언트와 소닉 ESB 서비스/프로세스 등) JMS 응용 프로그램은 점점 각 메시지에 JMSXDeliveryCount 속성 값에 작용하여 자신에 검출을 수행 할 수 있습니다. JMSXDeliveryCount 속성은 int를 사용하여 메시지에 대한 배달 시도 횟수를 지정합니다. javax.jms.Message.getIntProperty ("JMSXDeliveryCount") 메소드를 사용하여 값을 가져옵니다. 이 속성의 값은 메시지가 소비자에게 주어질 때마다 증가합니다. 소비자 개체에 배달되기 위해 대기중인 메시지에 대해 클라이언트 런타임에서 배달 카운터가 유지 관리됩니다. 소비자가 닫히거나 종료되고 다시 생성되거나 다시 시작되면 소비자에게 보낸 각 메시지의 카운터는 0으로 재설정됩니다.

Answer 2

JMSXDeliveryCount는 메시지가 소비자에게 다시 전달 될 때마다 증가합니다. 메시지를 다시 배달 할 수 있습니다.

1) 클라이언트 확인 모드를 사용하는 소비자가 이전에 해당 메시지에 대해 acknowledge()를 호출하지 않은 메시지를 받았습니다.

2) 소비자가 트랜잭션에서 메시지를 수신했거나 커밋을 호출하지 않았거나 롤백을 호출했습니다.

편집

:

JMS 클라이언트가 메시지를 처리 ​​할 수없는 경우 인해 나쁜 JMS 헤더로는, (포이즌 메시지라고도 함) 다음과 같은 메시지가 내부 응용 프로그램과 JMS 클라이언트로한다 전달되지 않습니다 그 메시지를 롤백하십시오. 이 경우 JMSXDeliveryCount도 증가합니다.

IBM MQ에서 메시지를 검색 할 큐에 대해 [백 아웃 큐] 및 [백 아웃 임계 값] 속성을 설정 했습니까? 백 아웃 임계 값에 도달하면 JMS 클라이언트는 잘못된 메시지를 백 아웃 대기열에 넣습니다. 이것은 동일한 메시지가 JMS 클라이언트에 의해 반복적으로 검색되는 것을 피하여 다른 좋은 메시지가 애플리케이션으로 전달되는 것을 차단합니다.