Encadeamentos

Os nós de processamento de mensagem e os analisadores devem trabalhar em um ambiente de instâncias múltiplas e encadeamentos múltiplos. Podem existir muitos objetos de nó ou de analisador, cada um deles com muitos elementos de sintaxe, e podem existir muitos encadeamentos executando métodos nesses objetos. O design do intermediário de mensagem assegura que um objeto de mensagem e quaisquer objetos pertencentes a ele sejam utilizados somente pelo encadeamento que recebe e processa a mensagem através do fluxo de mensagens.

Uma instância de um nó de processamento de fluxo de mensagens é compartilhada e utilizada por todos os encadeamentos que servem ao fluxo de mensagens no qual o nó está definido. Para analisadores, uma instância de um analisador é utilizada somente por um único encadeamento de fluxo de mensagens.

Uma extensão definida pelo usuário deve respeitar esse modelo, e deve evitar o uso de dados ou recursos globais que exijam semáforos para serializar o acesso através de encadeamentos. Tal serialização pode resultar em gargalos de desempenho.

As funções de implementação de extensões definidas pelo usuário, e quaisquer funções chamadas por ela, devem ser reentrantes. Todas as funções utilitárias de extensões definidas pelo usuário são completamente reentrantes.

Embora uma extensão definida pelo usuário possa criar encadeamentos adicionais se necessário, é essencial que o mesmo encadeamento retorne o controle ao intermediário na conclusão de uma função de implementação.Se isso não ocorrer a integridade do intermediário será comprometida e resultados imprevisíveis serão produzidos.

Modelo de Execução

Quando um grupo de execução é inicializado, as lils apropriadas são disponibilizadas para o tempo de execução. O processo de tempo de execução do Grupo de Execução é iniciado e cria um encadeamento de configuração dedicado. No ambiente de execução do fluxo de mensagens, o fluxo de mensagens é seguro quanto a encadeamentos. Você pode executar fluxos de mensagens simultaneamente em muitos encadeamentos do S.O., sem precisar considerar questões de serialização. Os nós definidos pelo usuário que você implementar não devem comprometer esse modelo de encadeamento. Observe os seguintes pontos:
  • Uma mensagem de entrada enviada a um fluxo de mensagens é processada somente pelo encadeamento que a recebeu. Nenhuma comutação de encadeamento ou de contexto ocorre durante o processamento de mensagens
  • As estruturas de dados acessadas por fluxos de mensagens são visíveis somente para um único encadeamento, e essas estruturas de dados existem somente pelo tempo de vida da mensagem que está sendo processada.
  • Uma única instância de um fluxo de mensagens é compartilhada entre todos os encadeamentos no conjunto de encadeamentos do fluxo de mensagens. Isso está relacionado com o comportamento de um nó de fluxo de mensagens no sentido de que ele não tem estado.
  • Os requisitos de memória de um Grupo de Execução não são afetados excessivamente pela execução de fluxos de mensagens em mais encadeamentos do S.O.

Modelo de Encadeamento

O exemplo de fluxo de mensagens a seguir o ajudará a compreender algumas das considerações sobre encadeamentos das quais você deve estar ciente ao projetar e implementar seus próprios nós definidos pelo usuário. Ele considera o exemplo de um nó input definido pelo usuário.

Um fluxo de mensagens pode ser configurado para executar em um conjunto de encadeamentos. Isso é determinado pelo número de nós de entrada no fluxo de mensagens e pelo valor da propriedade additionalInstances do fluxo de mensagens. Esses dois elementos determinam a capacidade máxima do conjunto de encadeamentos que o fluxo de mensagens pode utilizar. Portanto, se seu fluxo de mensagens tiver requisitos específicos de processamento que ditem a execução com um único encadeamento, você precisa assegurar que seja esse o caso.

Uma ordem típica de eventos para o processamento de nós de entrada é semelhante a esta:
  1. A construção do nó input ocorre
  2. Um encadeamento é requerido do conjunto de encadeamentos
  3. O encadeamento alocado inicia no método run do nó
  4. A configuração (ou reconfiguração) é consolidada
  5. O processamento de inicialização é executado no contexto do encadeamento
  6. O encadeamento se conecta ao gerenciador de filas do intermediário
  7. Um grupo de mensagens e um objeto de buffer são criados
  8. Um pedido queue open para a fila de entrada é enviado ao gerenciador de filas. Essa fila é mantida aberta pela duração do tempo de vida do encadeamento.
  9. O nó input entra num loop de processamento de mensagem
  10. Quando uma mensagem é recebida, o buffer de dados contém o cabeçalho e o corpo da mensagem
  11. Objetos de mensagem são criados e anexados ao grupo do encadeamento
  12. O dispatch de encadeamentos é ativado se encadeamentos múltiplos forem especificados
  13. Os dados da mensagem são propagados no recebimento de dados.
Você deve observar o seguinte:
  • Seu nó input implementará o modelo de encadeamento do fluxo de mensagens escolhido.
  • Seu nó input sempre terá pelo menos um encadeamento lendo de sua origem de entrada ou processando ativamente uma mensagem recebida por ele. Se um fluxo de mensagens tiver vários nós de entrada, quaisquer instâncias adicionais de encadeamento estarão disponíveis para atender a qualquer dos nós de entrada, conforme determinado pelo critério de dispatch desse nó input.
Os encadeamentos podem ser requeridos ou pedidos. Quando o fluxo de mensagens é implementado, o nó input exige um encadeamento inicial. Embora o fluxo de mensagens tenha um conjunto de encadeamentos associado a ele, é o nó input que é responsável pelo critério de dispatch. Isso significa que ele sempre precisa assegurar que uma instância dele próprio esteja em execução em um encadeamento. Como o valor padrão da propriedade additionalInstances é zero, quaisquer pedidos adicionais de um encadeamento falharão se você tiver definido vários nós de entrada. Isso significa que é possível que um fluxo de mensagens consuma mais encadeamentos do que o esperado. Além disso, poderia significar que se você tiver definido vários nós de entrada, um deles pode estar sem encadeamentos.

Permitir que o intermediário inicie cópias adicionais do fluxo de mensagens em encadeamentos separados utilizando a propriedade additionalInstances é a maneira mais eficiente de evitar que a fila de entrada se torne um gargalo. Contudo, a criação de encadeamentos separados permite o processamento paralelo de mensagens da fila de mensagens, e por isso essa propriedade deve ser utilizada somente quando a ordem em que as mensagens são processadas não for importante.

Os encadeamentos são criados como resultado da construção e operação do nó input. Um encadeamento permanece ativo ou inativo no conjunto de encadeamentos, e os encadeamentos inativos permanecem no conjunto até que sejam despachados por um nó input ou que o intermediário seja encerrado.

A figure a seguir ilustra a alocação de encadeamentos em um fluxo de mensagens.

Alocação de encadeamentos em um fluxo de mensagens


Consulte o texto associado para uma explicação dos elementos no diagrama

Inicialmente, Encadeamento 1 é requerido (A) e aguarda mensagens. Quando uma mensagem chega (B), Encadeamento 1 propaga a mensagem e despacha Encadeamento 2. Encadeamento 2 recebe uma mensagem imediatamente (C) e propaga e despacha Encadeamento 3, que aguarda uma mensagem (D). Encadeamento 1 conclui (E) e retorna ao conjunto de encadeamentos. Encadeamento 3 recebe então uma mensagem (F), despacha Encadeamento 1 e propaga a mensagem. Encadeamento 1 agora aguarda que uma mensagem chegue na fila (G).

Vale a pena observar o ponto marcado como H. Nesta instância no fluxo de mensagens, Encadeamento 1 adquire uma mensagem, mas como todos os outros encadeamentos estão ativos nesse momento, ele não pode despachar. A mensagem é propagada.

Depois que essa mensagem é propagada, Encadeamento 2 conclui (I), recebe uma nova mensagem da fila e propaga essa nova mensagem. Encadeamento 3 então conclui (J) e retorna ao conjunto. Encadeamento 2 então também é concluída (K). Como ele não despachou, quando Encadeamento 1 foi concluída (L) ele não pode retornar ao conjunto de encadeamentos embora não existam mensagens na fila, e em vez disso aguarda que uma mensagem chegue na fila.

Observe os seguintes pontos sobre o comportamento dos encadeamentos no WebSphere Message Broker:
  • Os encadeamentos são criados somente se requerido pela carga de trabalho. Isso significa que um processo de grupo de execução pode utilizar menos encadeamentos que os que tem configurados.
  • A menos que todos os encadeamentos disponíveis estejam processando ativamente dentro de um fluxo de mensagens, um encadeamento sempre estará lendo a fila de entrada.
  • Se a carga de trabalho aumentar em qualquer ponto, outros nós de entrada no mesmo fluxo de mensagens serão capazes de adquirir encadeamentos que tenham sido retornados ao conjunto de encadeamentos.
Se um encadeamento adquirir uma mensagem mas todos os outros encadeamentos estiverem ativos no momento, ele não poderá despachar. A mensagem é propagada. Quando esse encadeamento for concluído, como ele não despachou, não poderá retornar ao conjunto de encadeamentos mesmo que não existam mensagens na fila.
Tarefas relacionadas
Criando um Nó Input em C
Referências relacionadas
cniDispatchThread
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
as01460_