[ UNIX, Linux, Windows, IBM i ]

Configurando o comportamento de balanceamento usando o MQI

Para saber com precisão o momento exato em que o IBM® MQ fará o rebalanceamento de aplicativos, no momento da conexão, alguns ambientes de aplicativos cliente podem fornecer informações sobre o padrão de sistema de mensagens que está sendo utilizado.

No MQI, a estrutura de opções de balanceamento é conhecida como MQBNO.

Se não Opções de balanceamento são fornecidas em seu programa, os clientes de suporte obtêm essas informações no Estrofe do aplicativo ou ApplicationDefaults estrofe noclient.ini arquivo implantado junto com o aplicativo cliente.
Nota: Estas estrofes são idênticas, exceto a versão Application contém um campo Name para identificar em qual aplicativo estas opções se aplicam.

Se alguma dessas sub-rotinas for fornecida, é necessário que todos os campos estejam presentes, com exceção de BalanceOptions, cujo valor supõe-se ser none, quando não configurado explicitamente.

A ordem de preferência para o fornecimento das opções é:
  1. Uma estrutura MQBNO é fornecida pelo aplicativo em CONNX e utilizada em sua totalidade
  2. Ou, a correspondência denominada Application stanza, se presente, é exclusivamente usada para gerar um
  3. Ou a sub-rotina ApplicationDefaults, se houver, é usada exclusivamente para gerar uma estrutura
  4. Ou não há nenhum fluxo MQBNO para esta conexão.

Há três informações fundamentais que podem ser fornecidas a partir da estrutura MQBNO ou do arquivo client.ini:
  1. O ApplicationType ou padrão de aplicativo.

    Este campo indica para IBM MQ o padrão geral de atividade do IBM MQ em que esse aplicativo participa.

    São suportados três tipos de aplicativos:
    Simples
    Nenhuma regra específica deve ser aplicada além dos padrões descritos em comportamento de balanceamento de aplicação padrão .
    Solicitação-resposta
    Após cada chamada de MQPUT, espera-se uma chamada MQGET correspondente para uma mensagem de resposta. Veja Solicitar balanceamento de resposta para obter mais detalhes.
    Cliente gerenciado
    As solicitações de rebalanceamento são sempre despachadas imediatamente para o cliente, que faz o rebalanceamento em um momento que considerar adequado; por exemplo, isso poderia ser usado para o registro do adaptador de recursos JEE.
  2. O Timeout após o qual o rebalanceamento pode interromper a atividade do aplicativo
  3. BalanceOptions especificas

Exemplos de situações em que o aplicativo pode passar por rebalanceamento

Exemplo 1

Você gravou um aplicativo que coloca mensagens no ponto de sincronização e confirma o lote de mensagens emitindo uma chamada MQCMIT. Quando a chamada MQCMIT é concluída, o aplicativo começa a colocar mensagens em um novo ponto de sincronização.
Configuração sugerida para IBM MQ
Opções padrão suficientes
Resultado
Uma instância do aplicativo é movida quando uma chamada MQCMIT é bem-sucedida (ou falha), depois que o número de transações configuradas é atingido.

Por padrão, se um lote de mensagens exceder 10 segundos, ele pode ser atualizado em caso de solicitação de rebalanceamento. Caso se espere que esse limite seja regularmente excedido pelas transações e isso deva ser permitido, é possível estender o Timeout conforme necessário.

Exemplo 2

Você gravou um aplicativo que coloca uma mensagem em uma instância da fila de clusters e outro aplicativo responde para uma fila dinâmica temporária local com uma mensagem, depois de processar a solicitação. Após a leitura destrutiva da solicitação a partir da fila local, o aplicativo apresenta sua próxima mensagem de solicitação.
Configuração sugerida para IBM MQ
Configure Tipo como MQBNO_BALTYPE_REQREP
Resultado
Uma instância do aplicativo é movida quando um aplicativo conclui uma chamada MQGET e, nesse ponto, a instância do aplicativo é movida para outro gerenciador de filas. As chamadas MQPUT subsequentes serão executadas no novo gerenciador de filas.