Esta seção descreve alguns problemas comuns que podem surgir ao desenvolver fluxos de mensagens.Ela contém sugestões para lidar com os problemas:
Esse erro faz com que a mensagem seja direcionada para o terminal de falha.
Você pode haver conectado acidentalmente o terminal de falha do nó MQInput a um nó sucessivo em vez do terminal de saída. O terminal de saída é o terminal do meio dos três. As mensagens direcionadas a um terminal de saída não conectado são descartadas.
Se o terminal de falha do nó MQInput foi conectado, por exemplo, a um nó MQOutput, essas mensagens não aparecem.
Conectar um nó a um terminal de falha de qualquer nó indica que você projetou o fluxo de mensagens para lidar com todo o processamento de erros. Se você conectar um terminal de falha a um nó MQOutput, o fluxo de mensagens ignora os erros ocorridos.
Consulte a seção Utilizando o Rastreio para obter informações adicionais.
Essa ação produz uma entrada no rastreio de usuário de cada nó que a mensagem visitar, e somente desses nós.
Nas plataformas distribuídas, você pode recuperar as entradas de rastreio utilizando o comando mqsireadlog, formatá-las utilizando o comando mqsiformatlog e exibir os registros formatados para verificar o caminho da mensagem através do fluxo de mensagens. Consulte Comandos para obter informações adicionais sobre esses comandos.
Para o z/OS, edite e envie o job BIPJLOG do COMPONENTPDS para executar mqsireadlog e mqsiformatlog para processar rastreios. Consulte Jobs Utilitários do z/OS para obter informações adicionais sobre os comandos utilitários.
Envie a mensagem novamente ao fluxo de mensagens. O rastreio no nível de depuração produz muito detalhes adicionais sobre porque a mensagem está seguindo uma determinada rota e você poderá então determinar as razões para as ações tomadas pelo fluxo de mensagens.
Não se esqueça de desativar o rastreio quando tiver solucionado o problema ou o desempenho será afetado de forma adversa.
Em geral:
Se o fluxo de mensagens tiver caminhos que não são falhas, mas que não terminam em uma fila de saída (ou em outro armazenamento persistente), o fluxo de mensagens não terá falhado e a mensagem não é removida nem colocada em um destino alternativo (por exemplo, o terminal catch, a fila dead letter ou a fila de backout da fila).
SQL0954C Armazenamento insuficiente está disponível no heap do aplicativo para processar a instrução.No z/OS, um SQLSTATE de HY014 pode ser retornado com um código SQL igual a -99999, indicando que o processo DataFlowEngine atingiu o limite de processos do DB2 z/OS de 254 identificadores de instruções SQL preparadas.
Por razões de desempenho, depois que a instrução é preparada, a instrução e o identificador são salvos em um cache para reduzir o número de chamadas à função SQLPrepare. Se a instrução já estiver no cache, o identificador da instrução será retornado para que possa ser executado novamente com parâmetros recém-ligados.
A cadeia da instrução é utilizada para executar a consulta no cache. Utilizando cadeias SQL codificadas que diferem ligeiramente para cada mensagem, a instrução não é localizada no cache e uma função SQLPrepare é sempre executada (e um novo cursor ODBC é aberto). Ao utilizar as instruções PASSTHRU, utilize marcadores de parâmetros de forma que a mesma instrução SQL preparada possa ser utilizada para cada mensagem processada, sendo que os parâmetros são ligados no tempo de execução. Essa abordagem é mais eficiente em termos de recursos de banco de dados e, para instruções que são executadas repetidamente, é mais rápido.
Contudo, nem sempre é possível utilizar marcadores de parâmetros, ou você pode querer construir dinamicamente as cadeias das instruções SQL em tempo de execução. Isso potencialmente faz com que muitas instruções SQL únicas sejam armazenadas no cache. O próprio cache não cresce tanto, já que essas instruções em si geralmente não são grandes, mas muitas alocações de memória pequenas podem levar a fragmentação de memória.
Para qualquer fluxo de mensagens dado, um nó típico exige cerca de 2 KB do espaço da pilha do encadeamento Por padrão, existe, portanto, um limite de aproximadamente 500 nós em um único fluxo de mensagens na plataforma UNIX e de 1000 nós na plataforma Windows. Esse limite pode ser maior ou menor, dependendo do tipo de processamento que está sendo executado em cada nó.
Essa definição de variável de ambiente aplica-se a intermediários, portanto, o MQSI_THREAD_STACK_SIZE é utilizado para todos os encadeamentos que forem criados em um processo DataFlowEngine. Se o grupo de execução tiver muitos fluxos de mensagens designados a ele e um MQSI_THREAD_STACK_SIZE grande for definido, o processo DataFlowEngine precisará de uma grande quantidade de armazenamento para a pilha.
Video_Test#FCMComposite_1_1 ComIbmMQInputNode , Video_Test.VIDEO_XML_IN
Se for necessário analisar ou modificar os dados contidos em uma mensagem do WebSphere MQ Everyplace, utilize um MQeMbMsgObject. Isso fornece um paralelo às mensagens padrões do WebSphere MQ: você pode definir campos tais como correlation ID, e existe um campo que pode ser analisado utilizando qualquer analisador do WebSphere Business Integration Event Broker.
Conceitos relacionados
Mensagens do WebSphere MQ Everyplace
Fluxos de Mensagem
Tarefas relacionadas
Desenvolvendo Aplicativos do Fluxo de Mensagens
Tratando Erros em Fluxos de Mensagens
Utilizando o Rastreio
Lidando com Problemas
Referências relacionadas
WebSphere MQ Mobile Transport
Fluxos de mensagem
Nó MQInput
Avisos |
Marcas |
Downloads |
Biblioteca |
Suporte |
Feedback
![]() ![]() |
au16530_ |