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.
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.
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.
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.
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.
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).
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.
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:export MQSIJVERBOSE=-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider