이 주제에서는 서로 다른 요구사항에 맞도록 제공된 단순 집계 플로우를 수정하는 방법을 설명합니다. 버전 5 이하의 제품으로부터 기존 집계 플로우를 포팅 중인 경우에는 이 방법이 도움이 될 수도 있습니다.
특정 집계 조작의 상태 및 추적 정보가 들어 있는 제어 메시지를 전달하기 위해 Aggregate Control 노드의 Control 터미널을 사용합니다. 다음 세 가지 방법으로 이 Control 터미널을 사용할 수 있습니다.
이들 옵션 중 하나를 선택할 때 유념할 요인은 다음과 같습니다.
이전 릴리스의 제품에서 옵션 1은 Aggregate Control 노드의 시간 종료 구성 설정이 0으로 설정된 경우,
즉, 집계 조작이 결코 시간 종료되지 않는 경우에만 허용됩니다. 버전 6 제품에서 옵션 1은 집계 시간 종료의
사용 여부에 관계없이 모든 경우에 최적의 솔루션입니다. 최소량의 CPU를 사용하여 집계 상태를 저장하고 fan-out
플로우를 간소화합니다.
또한 제품 버전 6에서, 옵션 2 및 3을 사용하는 플로우는 투명하게
디폴트 옵션 1로 설정됩니다. 즉, Aggregate Control 노드의
Control 터미널 연결은 무시됩니다. 이는 플로우를 다시 작성하지 않아도
제품의 이전 버전으로부터 집계 플로우 효율성을 최대화합니다. 이 작동은 반대로,
브로커의 시동 환경에 MQSI_AGGR_COMPAT_MODE=ON
환경 변수를 내보내어 제어 메시지가 control 터미널(연결된 경우)로 전송되도록 할 수도 있습니다.
옵션 2는 시간 종료 처리에 관해서는 옵션 1과 기능적으로 동일하지만,
Control 터미널로부터 메시지 전달 및 Aggregate Reply 노드의 후속 처리에서 추가 처리 오버헤드가 발생합니다. 옵션 1에서와 같이 Aggregate Control 노드의 Control 터미널을 연결하지 않음으로써 이 오버헤드를
피할 수 있습니다.
옵션 3에서는 가장 종합적인 선택사항을 사용할 수 있습니다. 이 옵션을 선택하면 메시지 집계의 성능 및 작동에 밀접한 관계가 있다는 것을 알아두어야 합니다. 집계 메커니즘의 처리를 가장 효율적으로 수행하려면 fan-in 메시지 플로우의 Aggregate Reply 노드가 In 터미널에 메시지를 수신하기 전에 fan-out 메시지 플로우의 Aggregate Control 노드로부터 메시지를 수신해야 합니다.
어떤 상황에서는 이것이 해당되지 않을 수 있습니다. 예를 들어, fan-out된 요청 메시지에서
처리가 매우 빠르게 수행되었는데, 동시에 Aggregate Control 노드의 Control 터미널로부터
메시지 전달이 Compute 노드에서 처리될 때 지연되는 경우가 있습니다. 이는 Aggregate Reply 노드의 처리에 문제점을 일으킬 수 있습니다.
그러나 Aggregate Reply 노드의 알 수 없는 메시지 시간 종료 값이 0이 아니면 집계는 계속 올바르게
완료됩니다. 이 경우, 알 수 없는 응답이 저장된 다음, 시간 종료 기간 수가 지나면 다시 처리됩니다. 이때 이들 정보는 제어 상태 정보에 통합됩니다. 집계 조작은 알 수 없는 메시지 시간 종료의
만기에 의한 지연 이후 계속 올바르게 완료됩니다.
알 수 없는 메시지 시간 종료를 0으로 설정하면, 제어 메시지 앞에 오는 응답은
Aggregate Reply 노드의 Unknown 터미널로 직접 전달되고 나머지 집계 데이터와 통합되지 않습니다.
옵션 3은 다음의 이미지(잘려짐)와 유사하게 나타납니다.
AddMqmd Compute 노드는 이와 유사한 ESQL을 포함하고 있으며 제어 메시지를 큐에 쓸 수 있도록 합니다.
CREATE COMPUTE MODULE AggregationOut_AddMqmd
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;
Aggregate Control 노드가 제어 정보를 저장하기 전에 fan-in 플로우가 응답 메시지를 수신하지 못하게 하려면 fan-out 플로우에 있는 MQInput 노드의 트랜잭션 모드를 예로 설정해야 합니다.
fan-out 플로우가 트랜잭션 제어 아래에서 실행되지 않을 때, MQOutput 노드가 작성한 각 집계 fan-out 요청 메시지는 호출되고 있는 응용프로그램에 의해 즉시 처리될 수 있습니다. 이 응용프로그램의 응답에 따라, 응답은 제어 정보가 저장되기 전에 Aggregate Reply 노드에 수신될 수 있습니다.
Aggregate Control 노드의 Control 터미널이 Compute 노드와 MQOutput 노드에 연결된 경우, 즉 fan-in 및 fan-out 플로우가 서로 다른 메시지 플로우에 있을 경우 동일한 문제점이 발생할 수 있습니다. fan-out이 한 트랜잭션 아래에서 수행되었더라도 트랜잭션의 범위는 MQOutput 노드에 의한 메시지의 작성이므로 응답은 fan-in 플로우의 Control 분기가 처리되는 동안 계속 알 수 없는 응답으로 처리될 수 있습니다. 이는 위의 절, 옵션 3에서 설명되었습니다.
두 가지 경우 모두 Aggregate Reply 노드의 알 수 없는 메시지 시간 종료 값이 0이 아니면 집계는 계속 올바르게 완료됩니다. 알 수 없는 응답이 저장된 다음, 지정된 초 수가 지나면 다시 처리되며, 이때 이들 정보는 제어 상태 정보에 통합됩니다. 집계 조작은 알 수 없는 메시지 시간 종료의 만기에 의한 지연 이후 계속 올바르게 완료됩니다. 알 수 없는 메시지 시간 종료를 0으로 설정하면, 제어 메시지 앞에 오는 응답은 Aggregate Reply 노드의 Unknown 터미널로 직접 전달되고 나머지 집계 데이터와 통합되지 않습니다.
이 절과 이전 절을 모두 요약하려면 가장 효율적인 Aggregation fan-out 플로우 설계를 통해 다음을 확인해야 합니다.
이들 두 가지 설계 권장사항을 채택할 경우, 위에 설명된 유형의 시간 종료 문제점은 발생하지 않습니다. 그러나 어떤 이유 때문에 이들 권장사항을 따를 수 없을 경우, Aggregate Reply 노드의 알 수 없는 메시지 시간 종료 매개변수를 0이 아닌 값으로 설정하여 집계 조작이 성공적으로 완료되게 할 수 있습니다.
Aggregate Reply 노드에는 세 개의 오류 없는 출력 터미널인 Out, Unknown 및 Timeout 터미널이 있습니다. 트랜잭션 컨텍스트에 특별히 주의하면서 이들 서로 다른 터미널로부터 메시지가 송신된 시간과 이유를 이해할 필요가 있습니다. 트랜잭션 컨텍스트는 MQInput 노드에서 소유하거나(이는 수신되는 응답 메시지가 Aggregate Reply 노드로부터 출력을 트리거할 때 발생함) Aggregate Reply 노드 자체에서 소유할 수 있습니다.
Aggregate Reply 노드에서 소유할 때 트랜잭션 컨텍스트는 통상적인 의미를 갖지만, 트랜잭션 제어는 MQInput 노드 대신 Aggregate Reply 노드에 집중됩니다. 이러한 결과로 메시지 플로우에서 나중에 생성된 오류 때문에 Aggregate Reply 노드가 롤백되고 메시지는 MQInput 노드 대신 Catch 터미널로 전달됩니다. 자체 트랜잭션의 컨텍스트 내에서 Aggregate Reply 노드로부터 전달된 메시지는 MQInput 노드에서 직접 제공된 것이 아닙니다. Aggregate Reply 노드가 이 플로우 호출에 대한 입력 노드입니다.
Aggregate Reply 노드의 트랜잭션 작동은 해당 트랜잭션 모드 구성 매개변수에 의해 제어됩니다. 이 설정과 MQInput 노드의 설정이 동일한지 확인하여 Aggregate Reply 노드의 모든 출력이 같은 레벨의 트랜잭션 제어 하에 있게 해야 합니다.
다음은 MQInput 노드의 트랜잭션 제어 하의 상황입니다.
다음은 Aggregate Reply 노드의 트랜잭션 제어 하의 상황입니다.
Aggregate Reply 노드에는 In과 Control, 두 개의 입력 터미널이 있습니다. 이들 터미널을 모두 사용할 경우, Control 터미널을 사용하는 것이 선택사항인 것을 기억할 때 Aggregate Reply
노드로 데이터를 제공하는 가장 효율적인 방법은 fan-in 플로우에 대한 단일 MQInput 노드 다음에
Filter 노드를 오게 하는 것입니다. Filter 노드는 Aggregate Reply 노드의 In 또는 Control 터미널로 수신되는 메시지를 적절히 라우트하는 데
사용됩니다. 메시지 플로우에 두 개의 MQInput 노드(In 터미널에 하나, Control 터미널에 하나)를
사용하는 대신 이 방법을 사용하십시오. fan-in 플로우는 다음과 같아야 합니다.
메시지가 Aggregate Reply 노드의 적절한 터미널로 라우트되는지 확인하려면
Filter 노드에 아래와 유사한 ESQL 모듈이 있어야 합니다.
CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XML.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;
두 개의 MQInput 노드 사이에 추가 스레드(추가 인스턴스를 사용하여 사용 가능해짐)를 분배하는 방법을 지정할 방법이 없으므로 단일 MQInput 노드를 사용해야 합니다. Aggregate Reply 노드의 In 터미널에서 트래픽이 높을 수 있으므로 해당 입력 노드에서 더 많은 스레드를 실행하게 하는 것이 가장 유용하겠지만 이를 구성할 방법이 없습니다. 따라서 노드에 스레드 기아 현상이 나타나고 응답 메시지를 백업하며 집계 메커니즘을 지연시킬 수 있습니다.
이 사항은 Aggregate Contol 노드의 Control 터미널이 큐로 출력으로 연결되지 않은 경우에만 적용됩니다. Control 터미널을 연결하지 않음으로써 이 절에서 언급된 문제점을 극복할 수 있습니다.
마지막으로, 어떤 이유 때문에 위의 솔루션을 구현할 수 없는 경우 제어 메시지를 읽고 있는 MQInput 노드를 강제로 단일 스레드로 실행되게 할 수 있습니다. MQInput 노드 구성의 고급 패널에서 순서 모드를 큐 순서별로 설정하고 논리 순서를 선택하여 이를 수행할 수 있습니다. 이 방법은 구성된 추가 인스턴스를 모두 사용 가능하게 하여 다른 MQInput 노드에서 사용되게 합니다. 첫 번째 MQInput 노드의 성능이 상당히 제한되므로 마지막 수단으로만 이를 수행해야 합니다.