WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Gerenciamento de Conexões

As conexões TCP/IP são solicitadas pelo gerenciador de conexões do cliente e aceitas pelo gerenciador de conexões do servidor.

O processo do grupo de execução contém o gerenciador de conexões, que estabelece as conexões. Somente um grupo de execução pode ter nós de servidor usando uma porta específica a qualquer momento; a implementação em um segundo grupo de execução causa um erro de implementação. Nós clientes podem ser implementados em diferentes grupos de execução, mas cada grupo de execução possui seu próprio conjunto de conexões ,e, portanto, seus próprios número mínimo e máximo de conexões.

Os nós TCPIP não criam ou gerenciam diretamente nenhuma das conexões TCP/IP, mas as adquirem do conjunto interno do gerenciador de conexões. Por exemplo, dois nós de saída que utilizam os mesmos detalhes da conexão compartilham o mesmo gerenciador de conexões. Os nós TCPIP podem definir os detalhes da conexão a serem usados especificando um dos seguintes valores:

Se um nome do host e uma porta forem especificados, o nó utilizará estes valores ao solicitar conexões. Se um serviço configurável for especificado, o nó obterá os valores para a porta e nome do host dos valores definidos no serviço configurável. O gerenciador de conexões suporta outros parâmetros configuráveis, além do nome do host e da porta, e é possível definir todos esses valores quando se está utilizando um serviço configurável. Quando o nome do host e a porta forem especificados no nó, o gerenciador de conexões obterá o restante dos valores necessários do serviço configurável padrão. Entretanto, se um serviço configurável que está usando o nome do host e o número da porta for definido, os valores desse serviço configurável serão usados.

O gerenciador de conexões é criado quando o primeiro nó que requer conexões dele é implementado. O gerenciador de conexões é excluído quando o último nó restante que está o utilizando tiver sido removido do grupo de execução (o que significa que o gerenciador de conexões não está mais sendo utilizado por nenhum dos nós implementados). Por exemplo, esse processo pode ocorrer quando fluxos existentes são reimplementados, pois a reimplementação envolve excluir todos os nós existentes antes de recriá-los.

O gerenciador de conexões se aplica a todas as mudanças feitas a um serviço configurável TCPIPClient sem requerer um reinício dos grupos de execução. O gerenciador de conexões aplica as mudanças no serviço configurável TCPIP a todos os fluxos de mensagens que usam esse serviço. Aplicar mudanças de serviços configuráveis TCPIP implica em reiniciar os gerenciadores de conexão TCPIP, portanto, pode ser esperado que todos os fluxos que usam serviços configuráveis para especificar parâmetros TCPIP selecionem novas conexões TCPIP.

O gerenciador de conexões atualiza os nós afetados somente após cada fluxo de mensagens afetado ter processado a mensagem atual. Quando um fluxo de mensagens afetado tiver processado a mensagem atual, esse fluxo será bloqueado até que as atualizações em todos os fluxos de mensagens afetados sejam concluídas. Esse processo destina-se a assegurar que cada nó contido no mesmo grupo de execução use o mesmo valor para o serviço configurável modificado. Por essa razão, pode haver um atraso de vários segundos entre aplicar a atualização ao serviço configurável, e as propriedades usadas pelo fluxo de mensagens serem atualizadas.

Conexões do Servidor

O gerenciador de conexões do servidor começa a atender conexões do servidor ao ser iniciado e continua aceitando conexões até que o número máximo de conexões (especificado no serviço configurável) seja atingido. As tentativas de estabelecer conexões após este ponto serão rejeitadas. Os servidores TCP/IP não criam conexões; eles apenas aceitam solicitações de conexão de outros aplicativos. Com resultado, não é possível forçar a criação de conexões em um fluxo de mensagens.

Conexões do Cliente

O gerenciador de conexão do cliente inicia e continua fazendo conexões do cliente até o número mínimo de conexões (conforme definido no serviço configurável) for atingido. Por padrão, o número mínimo de conexões é zero, que significa que nenhuma conexão é feita. Sempre que o número de conexões ficar abaixo do valor mínimo, o gerenciador de conexões começará a criar mais conexões do cliente. Os nós de envio e recebimento do cliente iniciam a criação das novas conexões do cliente sempre que nenhuma estiver disponível para eles usarem, a menos que o número máximo (conforme definido no serviço configurável) tenha sido atingido.

Reservando e Liberando Conexões

Cada conexão tem um fluxo de entrada e um fluxo de saída, ambos dos quais possuem dois estados principais no gerenciador de conexão: disponível e reservado.

Quando um nó solicita uma conexão para entrada ou saída, sem especificar o ID de uma conexão específica, ele recebe qualquer conexão disponível no fluxo necessário. Se nenhuma conexão estiver disponível, e se o nó for um nó cliente, será estabelecida uma nova conexão, mas apenas se o número máximo de conexões ainda não tiver sido atingido. Qualquer conexão no estado disponível pode ser utilizada apenas por um nó de cada vez, mas quando um nó terminar de utilizá-la, qualquer outro nó (de qualquer fluxo ou encadeamento) poderá acessá-la.

É possível restringir o acesso a um fluxo em uma conexão, reservando a conexão. Quando uma conexão estiver no estado reservado, nenhum outro nó poderá acessar o fluxo sem especificar o ID da conexão. Por exemplo, um nó de entrada pode solicitar uma conexão disponível e, quando tiver concluído a leitura dos dados, colocar o fluxo no estado reservado. Enquanto o fluxo está no estado reservado, nenhum nó de entrada (incluindo o nó que coloca o fluxo no estado reservado) pode acessá-lo porque os nós de entrada podem acessar somente fluxos disponíveis. Os únicos nós que podem acessar o fluxo devem ter o ID de conexão, que é gravado no ambiente local de saída quando os dados são transmitidos ao fluxo de mensagens. Como resultado, os nós de recebimento podem ler mais dados na mesma conexão, mas somente se o nó de recebimento estiver configurado para usar o ID do ambiente local do nó de entrada.

Quando uma conexão estiver reservada, a propriedade da conexão será concedida a um encadeamento de processamento atual. Este processamento pode estender fluxos de mensagens separados, se necessário.

O mecanismo de reserva fornece as seguintes opções:
  • Deixar Inalterado
  • Reservar
  • Liberar
  • Reservar e liberar no final do fluxo

Para todos os nós, o fluxo é deixado disponível (não reservado) por padrão. Para muitos tipos de processamento, é possível deixar esse padrão inalterado; por exemplo, quando você está movendo dados de um fluxo de entrada para um arquivo. O principal propósito de reservar um fluxo é conectar uma série de nós para fornecer processamento complexo em um fluxo em uma sequência ordenada, controlada e síncrona.

É possível utilizar a opção Reservar e Liberar no Final do Fluxo para reservar uma conexão e garantir que o fluxo da conexão seja liberado quando uma iteração do fluxo de mensagens tiver concluído o processamento (incluindo quaisquer condições de erro que possam ocorrer).

Se for necessário que o processamento transponha vários fluxos de mensagens (por exemplo, para resposta e pedido assíncronos), será preciso reservar um fluxo sem liberá-lo no final do fluxo de mensagens. Consulte a amostra a seguir para obter um exemplo:

Você só pode visualizar informações sobre amostras quando usa o centro de informações que está integrado ao WebSphere Message Broker Toolkit ou o centro de informações on-line. Você só poderá executar amostras quando usar o centro de informações que está integrado ao WebSphere Message Broker Toolkit.

Uma desvantagem de reservar um fluxo entre fluxos de mensagens é o potencial para que um fluxo nunca seja liberado. Para evitar este problema, configure um horário de expiração na conexão para que ela seja encerrada após um período de inatividade especificado.

Outro benefício de reservar um fluxo de entrada é que a conexão não pode ser encerrada até ele tenha sido liberado ou expirado (mesmo se um aplicativo de encerramento fechar seu encerramento da conexão), o que é útil quando o final do fluxo está sendo usado para delimitar mensagens no fluxo.

Descritores de Arquivos

Se seu aplicativo WebSphere Message Broker estiver em execução no Sun Solaris 10 no SPARC, pode ser necessário aumentar o número de descritores do arquivo. O erro a seguir no syslog indica que descritores de arquivo adicionais são necessários:
 Falha ao criar uma conexão com o cliente usando o nome do host: '', port: ''. Razão: 'Invalid argument'
Também é possível tentar os dois métodos a seguir para resolver o erro:
  • Altere a variável de ambiente MQSIJVERBOSE, por exemplo:
    export MQSIJVERBOSE=-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider
  • Altere o limite máximo de identificadores de arquivos para value em vez de RLIM64_INFINITY
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:57


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ac67380_