Symptôme :
Les causes premières de ce problème tiennent à des défaillances d'E/S de socket sporadiques et rares, qui peuvent maintenir le logiciel appelant en attente de la fin d'une lecture indéfiniment.
Du point de vue des utilisateurs, cela se traduit par la suspension des processus qui se terminent normalement sans problème. Ces processus reprennent et se terminent comme prévu après un redémarrage de l'orchestrateur CA Process Automation. Ce problème peut affecter un sous-ensemble limité de processus ou tous les processus en cours d'exécution. Il n'est pas lié au temps de disponibilité de l'orchestrateur et peut se manifester après un redémarrage ou après plusieurs jours, plusieurs semaines ou plusieurs mois d'usage normal de l'orchestrateur.
Ce problème a uniquement été constaté dans les environnements exécutant des volumes élevés de processus CA Process Automation. Dans la plupart des environnements comprenant un NIC E1000, le problème n'est jamais survenu ou si rarement, qu'il n'a pas été détecté.
Solution :
Ce problème est très difficile à confirmer. S'il survient, le thread CA Process Automation est souvent bloqué sur une lecture de socket et aucune erreur pertinente n'est écrite dans les fichiers journaux. Pour confirmer le problème, vous devez vérifier une série d'images mémoire de thread Java prises au cours d'une occurrence pour confirmer que l'opérateur est bloqué sur une lecture de socket.
Lorsque des erreurs relatives à ce problème sont observées, elles tendent à indiquer des erreurs de connexion génériques qui peuvent avoir d'autres causes légitimes, mais sans rapport. Exemple d'erreurs :
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)
. . . and so on.
Dans ce cas, l'identification du problème est difficile et d'autres causes d'échec des communications doivent être exclues.
Un échec de processus fréquent ou l'échec d'un ou de plusieurs opérateurs qui se répète indique probablement que d'autres problèmes sans rapport existent dans la conception du processus ou la fonctionnalité de l'orchestrateur.
Sur les sites où la présence du problème a été confirmée, la reconfiguration du serveur VMware à partir d'un pilote de NIC E1000 vers un pilote de NIC VMXnet-3 offre une solution partielle très efficace.
Cette solution n'est pas considérée par CA Technologies comme une solution complète, car le taux d'incident de ce problème est très faible et le délai entre occurrences est assez long, même avec le NIC E1000.
Si vous voulez vérifier la présence du problème avant d'effectuer la modification du pilote, contactez le support de CA pour obtenir de l'aide lors de la configuration de la journalisation et des images mémoire de thread Java.
|
Copyright © 2013 CA.
Tous droits réservés.
|
|