[AIX Solaris HP-UX Linux Windows][IBM i]

Ordem Estrita de Mensagens Usando Portas do Listener não ASF

A ordem estrita de mensagens pode ser conseguida ao implementar aplicativos de bean acionado por mensagens para o provedor de sistema de mensagens do IBM MQ quando nenhum recurso especial foi codificado no aplicativo para manipular mensagens que chegam fora de ordem.

Para WebSphere Application Server Versão 7 e posterior, as portas listener são estabilizadas. Para obter informações adicionais, leia o artigo sobre recursos estabilizados. Você deve planejar migrar as configurações de implementação do bean acionado por mensagens do WebSphere MQ do uso de portas do listener para o uso de especificações de ativação. [AIX Solaris HP-UX Linux Windows][IBM i]Para obter informações adicionais sobre como configurar as especificações de ativação para o modo não ASF, veja Configurando especificações de ativação para o modo não ASF. No entanto, você não deve iniciar esta migração até ter certeza de que o aplicativo não precisa funcionar nos servidores de aplicativos anteriores ao WebSphere Application Server Versão 7. Por exemplo, se você possuir um cluster do servidor de aplicativos com alguns membros na Versão 6.1 e alguns em uma versão posterior, não deverá migrar os aplicativos nesse cluster para usar as especificações de ativação até depois de ter migrado todos os servidores de aplicativos no cluster para a versão posterior.

As seguintes suposições foram feitas neste cenário:
  • O aplicativo de bean acionado por mensagens (MDB) é transacional.
  • O limite de retorno (BOTHRESH) na fila do IBM MQ foi configurado como 0.

Configuração do WebSphere Application Server para Entrega Ordenada

  • O modo não ASF deve ser ativado especificando um valor de tempo limite diferente de zero para a propriedade customizada de serviço de listener de mensagens NON.ASF.RECEIVE.TIMEOUT do IBM MQ.
  • A configuração Máximo de Sessões para a porta do listener deve ser configurada como 1.
  • Uma porta do listener não ASF com Máximo de Sessões configurado como 1 possui um único encadeamento em execução dentro do servidor de aplicativos recebendo as mensagens. Quando uma mensagem chega, o encadeamento imediatamente a encaminha para o MDB.
  • O gerenciador de filas considera este encadeamento como um único aplicativo recebendo mensagens, portanto, as mensagens são processadas em sequência.

As mensagens podem ser entregues fora de ordem com esta implementação durante uma recuperação de transação

Um conjunto específico de eventos deve ocorrer em uma ordem específica para este cenário ser encontrado e, por sua vez, é incomum. Entretanto, se a entrega de mensagens ordenadas é essencial para a operação de seu aplicativo, então você deve considerá-la.

  • A entrega de mensagens fora de ordem pode ocorrer com esta opção de implementação durante a recuperação de uma falha de um dos seguintes componentes:
    • O servidor de aplicativos que hospeda o MDB.
    • O gerenciador de filas do IBM MQ
    • Uma rede conectando o servidor de aplicativos e o gerenciador de filas
  • Se um desses componentes falhar no meio de um processo two-phase commit de uma transação MDB, o gerenciador de transações do servidor de aplicativos reestabelecerá a conexão com o gerenciador de filas para resolver a transação quando o componente estiver disponível novamente.
  • Esse processo de recuperação é assíncrono e é possível que a entrega de novas mensagens para o MDB seja iniciada antes que o processo de recuperação da transação estiver concluído. Se o resultado da recuperação de transação for retroceder a transação, a mensagem será retornada para a fila do WebSphere MQ e entregue novamente para o aplicativo, provavelmente após novas mensagens já terem sido entregues.

Considerações para implementação em cluster

Quando você estiver usando portas do listener não ASF será possível configurar a opção (DEFSOPT) de compartilhamento padrão na fila como exclusive. Se você escolher esta opção quando estiver executando uma implementação em cluster de um aplicativo, todos os membros do cluster, exceto um, falharão ao iniciar suas portas do listener. O membros de cluster geram uma exceção 2042MORC_OBJECT_IN_USE em uma mensagem WMSG0057E.

Quando esta exceção ocorre, é possível estabelecer failover automático para o aplicativo configurando a seguinte propriedade customizada do serviço do listener de mensagens no WebSphere Application Server:

MAX.RECOVERY.RETRIES
Configure um valor alto para MAX.RECOVERY.RETRIES nos serviços do listener de mensagens de todos os servidores no cluster. O valor máximo para MAX.RECOVERY.RETRIES é 2147483647.
A propriedade customizada do serviço do listener de mensagens MAX.RECOVERY.RETRIES deve ser acompanhada por uma propriedade customizada do serviço do listener de mensagens MAX.RECOVERY.INTERVAL adequada. A quantidade máxima de tempo que uma porta do listener pode tentar novamente sem ser parada e reiniciada manualmente é 2147483647 vezes o valor especificado para MAX.RECOVERY.INTERVAL. Nesta configuração, cada membro de cluster tenta continuamente iniciar sua porta do listener, até que o membro de cluster ativo pare e o gerenciador de filas permita que ele se conecte como um único consumidor exclusivo.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_wmq_smo_nonasflp
Nome do arquivo: cmm_wmq_smo_nonasflp.html