Pergunta

Eu tenho um aplicativo JMS simples implantado no OC4J no servidor AIX, no meu aplicativo, estou ouvindo algumas filas e enviando para outras filas em um MQ WebSphere implantado no servidor AS400.

O problema é que minhas conexões com essas filas são encerradas/fechadas quando permanece ocioso por algum tempo com o erro MQJMS1016 (este não é o problema), e quando isso acontece, tento recuperar a conexão e ela funciona, no entanto, a conexão antiga está presa no MQ e não terminou até que seja encerrada manualmente.

O código de recuperação é o seguinte:

public void recover() {
    cleanup();
    init();
}

public void cleanup(){
    if (session != null) {
        try {
            session .close();
        } catch (JMSException e) {
        }
    }
    if (connection != null) {
        try {
            connection.close();
        } catch (JMSException e) {
        }
    }
}

public void init(){
    // typical initialization of the connection, session and queue...
}
Foi útil?

Solução 2

Como as conexões órfãs (conexões presas no lado MQ) não afetam o processamento das mensagens (ou seja, elas não consomem mensagens), deixamos as coisas como é até que as conexões máximas permitidas no MQ fossem atingidas.

A recuperação não funcionou mais e, quando chegamos a esse ponto, o administrador do MQ teve que limpar a conexão órfã manualmente, no entanto, a boa notícia é que a busca por esse problema em particular levou a um problema relatado no site de suporte da IBM:

Verifique aqui

Outras dicas

O MQJMS1016 é um erro interno e indica que a perda de conexão é devido a algo errado com o código ou o próprio WMQ. Ajustar os canais ajudará, mas você realmente precisa chegar ao problema de por que o aplicativo está vomitando conexões órfãs com rapidez suficiente para esgotar todos os canais disponíveis.

A primeira coisa que eu gostaria de fazer é verificar as versões do WMQ e do cliente WMQ que está em execução. Se esse é um novo desenvolvimento, certifique-se de estar usando o cliente WMQ V7 porque o V6 está no fim da vida a partir de setembro de 2011. O cliente V7 trabalha com o V6 QMGRS até que você também possa atualizar isso. Depois de chegar ao V7 Client e QMGR, há um pouco de opções de ajuste e reconexão de canal disponíveis.

O download do cliente WMQ V7 está aqui: http://bit.ly/bxm0q3

Além disso, observe que a lógica de reconectar no código acima não dorme entre as tentativas. Se um cliente lançar solicitações de conexão a uma alta velocidade, poderá sobrecarregar o ouvinte WMQ e executar um ataque do DOS muito eficaz. Recomendado para dormir alguns segundos entre as tentativas.

Finalmente, por favor, impede as exceções vinculadas em seus blocos de captura jmsexception. Se você tiver um problema com um provedor de transporte JMS, a exceção vinculada do JMS conterá quaisquer informações de erro de baixo nível. No caso do WMQ, ele contém o código da razão, como 2035 MQRC_Authorization_error ou 2033 MQRC_NO_MSG_AVALELE. Aqui está um exemplo:

try {
  .
  . code that might throw a JMSException
  .
} catch (JMSException je) {
  System.err.println("caught "+je);
  Exception e = je.getLinkedException();
  if (e != null) {
    System.err.println("linked exception: "+e);
  } else {
    System.err.println("No linked exception found.");
  }
}

Se você receber um erro às 2 da manhã, seu administrador WMQ agradecerá as exceções vinculadas.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top