Sintoma:
As principais causas desse problema são falhas raras e esporádicas de E/S de soquete, que podem fazer com que o software de chamada aguarde indefinidamente pela conclusão de uma leitura.
Da perspectiva dos usuários, o sintoma mais típico seria a suspensão inesperada de processos que normalmente são concluídos sem problemas, e que são retomados e concluídos como esperado após a reinicialização do orquestrador do CA Process Automation. Isso pode afetar um pequeno subconjunto de processos ou todos os processos em execução. Não tem correlação com o tempo de atividade do orquestrador e talvez se manifeste pouco depois de uma reinicialização, ou após dias, semanas ou meses de funcionalidade sem falhas do orquestrador.
Esse problema só foi visto em ambientes que executam altos volumes de processos do CA Process Automation. Na maioria dos ambientes onde o E1000 NIC está instalado, o problema nunca ocorreu ou ocorre com uma frequência tão baixa que não foi detectado.
Solução:
Esse problema é muito difícil de ser confirmado. Se esse problema ocorrer, geralmente o thread do CA Process Automation está parado em uma leitura do socket e nenhum erro relevante é gravado nos arquivos de log; a confirmação do problema exige a revisão de uma série de despejos de thread do Java executados durante uma ocorrência deste problema para confirmar se o operador está parado em uma leitura do socket.
Quando erros relacionados a esse problema são observados, geralmente indicam erros de conexão genéricos, que poderiam ter outras causas legítimas e não relacionadas. A seguir está um exemplo:
2013-07-24 18:55:23.219 WARN [org.hibernate.jdbc.AbstractBatcher] [nPool Worker-23] exception clearing maxRows/queryTimeout com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerStatement.checkClosed(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerStatement.getMaxRows(Unknown Source) at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.getMaxRows(CachedPreparedStatement.java:367) at org.jboss.resource.adapter.jdbc.WrappedStatement.getMaxRows(WrappedStatement.java:378) at org.hibernate.jdbc.AbstractBatcher.closeQueryStatement(AbstractBatcher.java:272) at org.hibernate.jdbc.AbstractBatcher.closeQueryStatement(AbstractBatcher.java:209)
. . . e assim por diante.
Nesses casos, a identificação do problema exige testes, e outros motivos de falha de comunicação devem ser excluídos.
Falhas do processo frequentes ou uma falha repetida de um operador individual ou de vários operadores provavelmente indicam outros problemas não relacionados na criação do processo ou na funcionalidade do orquestrador.
Em sites onde este problema foi confirmado, a reconfiguração do servidor da VMWare de um driver de placa de interface de rede E1000 para um driver VMXnet-3 NIC parece ser uma mitigação muito eficiente.
A CA Technologies evita declarar que esta é uma resolução completa, uma vez que a taxa de incidente é muito rara e o período entre as ocorrências, mesmo com o E1000 NIC, pode ser muito longo.
Se a verificação da ocorrência for necessária antes de fazer essa alteração, entre em contato com o Suporte para obter assistência para configurar o sistema de log e os despejos de thread do Java necessários para solucionar problemas e verificar esta ocorrência em particular.
|
Copyright © 2013 CA.
Todos os direitos reservados.
|
|