메시지 정렬
메시지 정렬은 일부 비동기 메시징 애플리케이션에서 중요합니다. 즉, 메시지 생성자가 메시지를 전송한 것과 동일한 순서로 메시지를 이용하는 것이 중요합니다. 사용 중인 애플리케이션에서 이러한 유형의 메시지 정렬이 중요한 경우 디자인에 이러한 사항을 고려해야 합니다.
예를 들어 좌석 예약을 처리하는 메시징 애플리케이션에는 생성자 컴포넌트와 이용자 컴포넌트가 있습니다. 고객이 좌석을 예약하는 경우 생성자 컴포넌트는 이용자 컴포넌트로 메시지를 전송합니다. 고객이 예약을 취소하면 생성자(다른 생성자일 수 있음)가 두 번째 메시지를 전송합니다. 일반적으로 이용자 컴포넌트는 두 번째 메시지(예약 취소)를 처리하기 전에 첫 번째 메시지(좌석 예약)를 처리해야 합니다.
일부 애플리케이션에서는 생성자가 다음 메시지를 전송하기 전에 각 메시지에 대한 응답을 기다리는 동기식(요청-응답) 패턴을 사용합니다. 이러한 유형의 애플리케이션에서 이용자는 메시지 수신 순서를 제어하고 해당 순서가 생성자가 메시지를 전송한 순서와 동일함을 보장할 수 있습니다. 다른 애플리케이션에서는 생성자가 응답을 기다리지 않고 메시지를 전송하는 비동기(실행 후 잊음) 패턴을 사용합니다. 이러한 유형의 애플리케이션에서도 일반적으로 순서는 유지됩니다. 즉, 이용자는 특히, 연속 메시지 전송 간격이 긴 경우 생성자가 메시지를 전송한 것과 동일한 순서대로 메시지를 수신할 것을 기대할 수 있습니다. 그러나 디자인에 이러한 순서를 바꿀 수 있는 요소를 고려해야 합니다.
애플리케이션에서 다른 우선순위를 사용하여 메시지를 전송하는 경우(우선순위가 높은 메시지가 우선순위가 낮은 메시지보다 먼저 전송) 또는 메시지 선택기를 지정하여 애플리케이션에서 첫 번째 이외의 메시지를 명시적으로 수신한 경우에는 메시지 순서가 바뀝니다. 또한 병렬 처리 및 오류 또는 예외 처리로 인해 메시지 순서가 바뀔 수도 있습니다.
병렬 처리
- 복수 대상
- 생성자가 하나의 대상으로 메시지를 전송한 다음 다른 대상으로 두 번째 메시지를 전송한 경우 첫 번째 메시지가 대상에 도착하기 전에 두 번째 메시지가 자신에게 지정된 대상에 먼저 도착할 수 있습니다. 생성자가 동일한 트랜잭션 내에서 두 개의 메시지를 모두 보낸 경우에도 이러한 상황이 발생할 수 있습니다. 트랜잭션은 두 개의 메시지가 모두 실패 또는 완료됨을 보장하지만 전달 순서를 보장하지는 않습니다. 이러한 경우가 애플리케이션에서 문제가 되면 해당 애플리케이션에 하나 이상의 대상을 사용하지 마십시오.
- 다중 생성자
- 하나의 생성자가 대상으로 메시지를 전송한 다음 두 번째 생성자가 동일한 대상으로 두 번째 메시지를 전송한 경우 첫 번째 메시지가 대상에 도착하기 전에 두 번째 메시지가 먼저 도착할 수 있습니다. 두 번째 생성자가 첫 번째 생성자와 동기화되는 경우에도 이러한 상황이 발생할 수 있습니다. 예를 들어 두 번째 메시지를 전송하기 전에 첫 번째 생성자의 신호를 기다라는 경우입니다. 또한 생성자가 트랜잭션 중심적인 경우에도 이러한 상황이 발생합니다. 이러한 경우는 트랜잭션이 완료되었다는 사실이 메시지가 대상에 도착했음을 의미하지 않습니다. 즉, 서비스 통합에서 먼저 트랜잭션을 완료한 후 메시지를 전달할 수 있습니다. 이러한 경우가 애플리케이션에서 문제가 되면 해당 애플리케이션에 하나 이상의 생성자를 사용하지 마십시오. 마찬가지로 여러 병렬 스레드를 실행하는 단일 생성자를 사용하지 마십시오.
- 다중 이용자
- 다중 이용자가 있는 큐 유형 대상에 두 개의 메시지가 도착한 경우 하나의 이용자가 첫 번째 메시지를 수신하고 다른 이용자가 두 번째 메시지를 수신할 수 있습니다. 이용자가 병렬로 실행되면 두 번째 메시지를 수신한 이용자가 첫 번째 메시지를 수신한 이용자보다 먼저 메시지를 처리할 수 있습니다. 또한 하나의 이용자가 트랜잭션상에서 메시지를 수신한 다음 트랜잭션을 롤백한 경우 다른 이용자가 해당 메시지를 수신할 수 있는 대상으로 이 메시지를 리턴합니다. 그 동안 다른 이용자는 이미 후속 메시지를 수신하여 처리했을 수 있습니다. 이러한 경우 중 한 가지가 애플리케이션에서 문제가 되면 해당 애플리케이션에 하나 이상의 이용자를 사용하지 마십시오. 마찬가지로 엔드포인트당 다중 동시 MDB(메시지 구동 Bean) 호출을 허용하지 마십시오(기본 메시징 제공자의 MDB 조절 구성 참조). 또는 엄격한 메시지 순서 사용을 고려하려면 버스 대상의 엄격한 메시지 순서를 참조하십시오.
- 클러스터링 및 파티션된 대상
- 하나 이상의 메시지 엔진이 있는 클러스터 버스 멤버에 큐 유형 대상이 지정되면 각 메시징 엔진에는 대상(대상 큐 위치 중 한 곳)의 파티션이 포함됩니다. 서비스 통합은 해당 대상의 다른 메시지를 다른 파티션으로 전달할 수 있습니다. 이러한 큐 유형 대상 구성은 뛰어난 가용성, 확장성 및 로드 밸런스를 제공하지만 일반적으로 메시지 정렬이 중요한 애플리케이션에는 적합하지 않습니다. 서비스 통합은 동일한 대상의 여러 파티션으로 전송된 메시지의 순서를 보장하지 않습니다. 또한 메시징 엔진에 포함된 대상 파티션에 메시지가 있으면 메시징 엔진을 시작할 수 없습니다. 메시징 엔진을 시작해야 이용자가 이러한 메시지를 사용할 수 있습니다. 그러나 서비스 통합에서는 계속해서 최신 메시지를 다른 메시징 엔진에 있는 다른 파티션으로 전달하고 이용자는 실패한 메시징 엔진 파티션에 있는 이전 메시지보다 먼저 새 메시지를 수신하여 처리할 수 있습니다. 큐 대상을 갖는 워크로드 공유에서는 이러한 유형의 구성에 대해 보다 자세히 설명하고 클러스터가 다른 서비스 통합 버스에 있는 경우가 아니라도 해당 클러스터 내에서 단일 생성자와 단일 이용자 간에 메시지 정렬을 유지할 수 있는 메시지 유사성 옵션을 사용하는 방법에 대해서도 설명합니다.
- 공개 및 등록
- 공개-등록 메시징의 경우 공유를 허용하도록 설정된 지속 가능한 등록 공유 특성을 사용하여 작성된 지속 가능한 등록의 개별 인스턴스를 비롯한 등록의 다른 인스턴스에서 수신한 메시지 순서를 서비스 통합이 보장하지 않습니다.
오류 및 예외 조건
- 서비스 품질
- 메시지에 대한 서비스 품질은 오류 및 예외 조건이 메시지 전달에 영향을 미치는 방식을 결정합니다(메시지 신뢰성 레벨 - JMS 전달 모드 및 서비스 통합 서비스 품질(QoS) 참조). 서비스 품질에 따라 오류 및 예외 조건으로 인해 서비스 통합에서 메시지를 확실히(정확히 한 번 전달) 전달하거나 약간 불확실하게(한 번 이상 전달 또는 전달하지 않음) 전달할 수 있습니다. 예를 들어 서비스의 품질이 명확히 비지속적인 상태이면 실패 후 메시지 순서가 다시 전달될 수 있습니다. 그러나 메시지 전달의 기본 순서는 항상 유지되어 1, 2, 3, 2, 3, 4의 순서로 메시지가 도착합니다. 보다 일반적으로 서비스 통합은 다른 서비스 품질 상태로 전송된 다른 메시지 순서를 보장하지 않습니다. 이러한 경우가 사용 중인 애플리케이션에서 문제가 되면 적절한 서비스 품질을 선택하고 동일한 대상으로 전송한 메시지에 다른 서비스 품질을 사용하지 마십시오.
- 예외 대상
- 특정 실패 시나리오에서 서비스 통합은 예외 대상으로 메시지를 전달하거나 대상으로 메시지를 전달한 다음 예외 대상으로 해당 메시지를 전송할 수 있습니다. 서비스 통합에서는 예외 대상으로 전송한 메시지의 순서를 보장하지 않습니다. 이러한 경우가 애플리케이션에서 문제가 되면 예외 대상을 사용하지 않도록 대상을 구성할 수 있습니다(예외 대상 참조). 생성자와 대상이 서로 다른 버스에 있으면 예외 대상이 없도록 해당 버스 간에 링크를 구성할 수 있습니다(외부 버스 및 외부 버스에 대한 링크의 예외 대상 처리 구성 참조).
- 트랜잭션 롤백
- MDB(메시지 구동 Bean)에 대한 활성화 스펙은 실패 메시지 재시도 간에 지연을 지정할 수 있습니다. 이러한 지연은 동일한 메시지가 해당 MDB를 다시 구동하기 전에 복구하도록 롤백하는 조건에 시간을 허용할 수 있습니다. 그러나 이러한 방식으로 메시지가 지연되면 다른 이후 메시지가 해당 MDB를 구동할 수 있습니다(시스템 자원 문제점으로부터 MDB 애플리케이션 보호 참조). 이러한 경우가 애플리케이션에서 문제가 되면 하나의 MDB에 최대 연속 실패 수를 제한하도록 고려하거나(JMS 활성화 스펙 [Settings] 참조) 엄격한 메시지 순서 사용을 고려합니다(버스 대상의 엄격한 메시지 순서 참조).
- 인다우트 트랜잭션 해석
- 2단계 커미트 처리 중 JMS 전송 또는 수신 조작이 인다우트 상태에 있으면 애플리케이션에서 실패가 발생할 수 있습니다. 이러한 경우 인다우트 상태를 처리하기 전에 해당 애플리케이션을 다시 시작할 수 있습니다. 따라서 애플리케이션 다시 시작 시 하나 이상의 메시지가 "표시되지 않지만" 이후에 "표시"됩니다. 이 때 대상의 다른 메시지에는 영향을 미치지 않습니다. 이용 애플리케이션에서는 인다우트 트랜잭션을 처리한 후 논리적으로 "표시되지 않는" 메시지(메시지 1) 다음에 오는 메시지(메시지 2)를 수신할 수 있습니다. 해당 애플리케이션은 이전에는 "표시되지 않는" 메시지(메시지 1)를 수신합니다. 이러한 방식으로 해당 애플리케이션은 잘못된 순서로 메시지를 수신하여 처리할 수 있습니다. 이러한 경우가 애플리케이션에서 문제가 되면 엄격한 메시지 순서 사용을 고려합니다(버스 대상의 엄격한 메시지 순서 참고).