지점간 메시지가 원격 메시지 지점을 통하여 도달하지 않는 이유 조사하기

메시지가 원격 메시지 지점을 통하여 라우팅될 때, 지점간 메시지가 서비스 통합 버스의 대상에 도달하지 않는 이유를 조사하기 위해 수행할 수 있는 일련의 확인 사항들이 있습니다.

시작하기 전에

이 태스크를 진행하기 전에, 수행해야 할 예비 확인 사항과 조사 태스크를 포함하는 Investigating why point-to-point messages are not arriving의 단계를 따르십시오.

이 태스크 정보

Investigating why point-to-point messages are not arriving의 일부로 이 태스크를 착수해야 합니다. 이 태스크는 메시지가 원격 메시지 지점을 통하여 라우팅되는 지점간 메시징 시나리오에서의 메시지 흐름을 조사하는 방법을 설명합니다. 다음 다이어그램에서는 버스에 세 개 메시징 엔진(ME1, ME2, ME3)이 포함됩니다. 생성 애플리케이션은 ME1에 연결되며 이용 애플리케이션은 ME3에 연결됩니다. 메시지는 ME1에 생성되며 ME1에서 ME2를 통하여 ME3으로 라우팅됩니다. 이 시나리오는 ME1과 ME2만 관여합니다. ME1은 ME2에 의해 호스팅되는 메시지 지점을 나타내는 원격 메시지 지점을 호스팅합니다. ME1은 생성 애플리케이션이 접속된 메시징 엔진이며, ME2는 큐 지점을 호스팅하는 메시징 엔진입니다.

이 메시징 엔진은 다음 단계에서 참조됩니다.

그림 1. 원격 메시지 지점을 사용하여 지점간 메시지 생성 이 그림은 주변 텍스트에서 설명합니다.

프로시저

  1. 서비스 통합 -> 버스 -> bus_name -> [토폴로지] 메시징 엔진 -> engine_name를 클릭하여 ME1에 대한 특성을 표시하십시오.
  2. ME1의 런타임 탭에서 [원격 메시지 위치] 원격 큐 지점를 클릭한 다음 ME2의 큐 지점를 나타내는 원격 큐 지점를 클릭하십시오. 현재 아웃바운드 메시지 필드의 값을 검토하십시오.
  3. 현재 아웃바운드 메시지 수가 0보다 큰 경우 메시지가 생성되었지만 ME2가 수신하지 않았을 수 있습니다.
    1. 두 메시징 엔진이 서로 통신할 수 있는지 확인하십시오. 서비스 통합 문제점 해결: 버스의 두 메시징 엔진 간 통신 확인의 내용을 참조하십시오.
    2. 큐에서 이전 메시지를 찾으십시오. 이전 메시지가 있으면서 그들 중 일부 또는 모두가 ME2에 대한 것인 경우, 잠시 기다린 후 보기를 새로 고치십시오.
      • 메시지의 일부가 큐에서 사라진 경우 시스템은 메시지를 전달하지만 백로그됩니다. 백로그가 지워질 때까지 기다린 다음, ME2의 큐 지점을 조사하여 테스트 메시지가 도달했는지 확인하십시오.
      • 메시지가 큐에서 하나도 사라지지 않은 경우, 메시지의 전송은 Committing 상태로 트랩된 메시지에 의해 차단될 수 있습니다. 나중 메시지는 이 메시지가 전달될 때까지 기다려야 하며, 그렇지 않으면 메시지의 순서가 손상됩니다.

        메시지가 Committing 상태로 트랩되면, 해당 메시지는 미해결 트랜잭션에 포함됩니 다. 데이터베이스와 같은 자원 관리자는 정지되어 있을 수 있습니다. 자원 관리자와 함께 이 문제를 해결하십시오. 이것이 실패하면 메시지의 트랜잭션 ID를 주목하고 서버 -> 서버 유형 -> WebSphere 애플리케이션 서버 -> server_name -> 런타임 > [추가 특성] 트랜잭션 서비스를 클릭하여 트랜잭션 서비스에 대한 일반 특성을 표시하십시오. 검토 링크를 사용하여 글로벌 ID가 메시지의 트랜잭션 ID와 일치하는 트랜잭션을 해결하십시오.

    3. 테스트 메시지의 상태를 확신하십시오.
      • 테스트 메시지의 상태가 "전송 보류 중"인 경우 메시지는 전송 대기 중입니다. ME2는 메시지를 수락하지 않을 수 있습니다. 다음 확인 사항을 완료하십시오.
        • 두 메시징 엔진이 서로 통신할 수 있는지 확인하십시오. 서비스 통합 문제점 해결: 버스의 두 메시징 엔진 간 통신 확인의 내용을 참조하십시오.
        • ME2의 큐 지점이 가득 차지 않았는지 확인하십시오. 큐 지점에 대한 런타임 특성을 표시하고 현재 메시지 깊이높은 메시지 임계값을 비교하십시오. 현재 메시지 깊이가 높은 메시지 임계값과 같은 경우, 큐 메시지가 이용되어야 메시지 엔진은 새 메시지를 승인할 수 있습니다. 이용자를 다시 시작하고 백로그가 지워질 때까지 대기하거나 메시지를 삭제하십시오.
          참고: 삭제된 메시지는 복구할 수 없습니다.
        • 구성 변경사항에 전파되었는지 확인하십시오. 최신 구성 설정을 ME2 애플리케이션 서버에 배치하여 ME2가 큐 지점 존재를 알고 있는지 확인하십시오.
      • 테스트 메시지 상태가 "수신확인 보류"인 경우에는 메시지가 전송되었지만 ME2가 메시지를 수신하지 않았거나 메시지를 처리하지 않은 것입니다. 전송 큐에서 테스트 메시지 앞에 커미트 상태의 메시지가 없는지 확인하고 잠시 후 큐 지점를 다시 검사하여 테스트 메시지가 도달했는지 여부를 확인하십시오. 커미트 상태에서 고정된 메시지가 있는 경우에는 다음 사항을 참조하여 이 문제점을 해결하십시오.
      • 테스트 메시지(또는 다른 메시지)가 Committing 상태인 경우 메시지는 미해결 트랜잭션에 포함됩니다. 데이터베이스와 같은 자원 관리자는 정지되어 있을 수 있습니다. 자원 관리자 관련 문제를 해결하십시오. 이것이 실패하면 메시지의 트랜잭션 ID를 주목하고 서버 -> 서버 유형 -> WebSphere 애플리케이션 서버 -> server_name -> 런타임 > [추가 특성] 트랜잭션 서비스를 클릭하여 트랜잭션 서비스에 대한 일반 특성을 표시하십시오. 검토 링크를 사용하여 글로벌 ID가 메시지의 트랜잭션 ID와 일치하는 트랜잭션을 해결하십시오.
  4. 완료된 아웃바운드 메시지의 수가 0보다 크면 메시지는 생성되고 ME2에 의해 처리되었지만 테스트 메시지는 표시되지 않았습니다. 생성 애플리케이션을 재실행하고 ME1의 완료된 아웃바운드 메시지의 수가 증가했는지 확인하십시오. (완료 아웃바운드 메시지 수가 증가하기 전에 활성 아웃바운드 메시지 수가 증가하는 것을 볼 수 있습니다.)
    • 수가 증가하지 않으면 메시지는 ME1에서 생성되지 않았습니다. 생성 애플리케이션이 이 메시징 엔진에 연결되었는지 확인하십시오(애플리케이션이 연결된 메시징 엔진 판별 참조).
    • 수가 증가하면 메시지는 ME2에 도달했지만 이용되었거나 예외 대상으로 전송되었거나 만료되었습니다. 이용자의 존재에 대해 확인하고 예비 확인 사항을 다시 완료하십시오.
  5. 현재 및 완료 메시지의 수가 모두 0인 경우, 생성 애플리케이션이 관련 예비 확인 사항을 다시 수행하여 이 대상으로 메시지를 생성하는지 확인하십시오.

다음에 수행할 작업

여전히 문제가 있다면 IBM 고객 서비스 담당자에게 문의하십시오.

주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tju_pt2pt_not_arriving_remote
파일 이름:tju_pt2pt_not_arriving_remote.html