WAS에서 대기열 X를 작성했습니다. 또 다른 대기열 Y를 작성했으며 MQ에서 Y가 X에 대한 백 아웃 대기열임을 지정합니다.
이제 X에 대해 최대 재시도 횟수 : 3이고 백 아웃 임계 값은 2입니다. 즉, 메시지가 X에 의해 소비되지 않으면 2를 시도한 후에 큐 관리자는 Y에 메시지를 넣습니다.이 경우 최대 재시도 횟수 (3)는 절대로 그것이 세 번째 시도를 결코 시도하지 않을 것이기 때문에 도달했습니다. 그리고 X에 대한 청취자는 절대로 내려 가지 않을 것입니다. 내 이해가 맞습니까?MQ 최대 재시도 횟수 및 백 아웃 임계 값
jms 인터페이스에 대해서는 잘 모르겠지만 기본 WMQ에서는 큐 관리자가 자동으로 백 아웃 대기열에 메시지를 다시 큐잉하지 않습니다. backout_count를 쿼리하고 backout_threshold와 비교하여 메시지를 backout_queue에 넣는 것은 응용 프로그램의 책임입니다.
당신은 "WebSphere Application Server가 포이즌 메시지를 처리하는 방법"을 읽어야합니다 - 읽어하는 것이 중요합니다 또한 http://www.ibm.com/developerworks/websphere/library/techarticles/0405_titheridge/0405_titheridge.html
을 "모범 사례 :는 WebSphere MQ 공유 큐와 응용 프로그램을"실행 아래로 스크롤 6-http://www.ibm.com/developerworks/websphere/library/techarticles/0512_elkins/0512_elkins.html
MQ JMS 구현은 대상 대기열에 설정된 백 아웃 임계 값에 도달하면 메시지를 백 아웃 대기열로 이동시키는 작업을 수행합니다. 백 아웃 큐가 지정되지 않으면 MQ JMS는 메시지를 데드 - 레터 큐에 넣으려고 시도합니다.
알고있는 한 MQ JMS에는 재시도 개념이 없습니다. WAS/MDB와 관련이있을 수 있습니다.
응용 프로그램이 msg to backout queue를 다시 큐잉하기로 결정했다면 백 아웃 임계 값이 큐의 속성에 정의 된 이유는 무엇입니까? 이 임계 값 특성은 어플리케이션에서 정의되어서는 안됩니다.
매우 혼란 스럽습니다.