Fehlerbehebung › Potenzielles Problem wenn CA Process Automation auf einem VMWare-Server mit einer E1000-Netzwerkschnittstelle ausgeführt wird

Potenzielles Problem wenn CA Process Automation auf einem VMWare-Server mit einer E1000-Netzwerkschnittstelle ausgeführt wird

Symptom:

Die Ursachen dieses Problems sind in seltenen Fällen Socket-I/O-Fehler, die dazu führen können, dass die Software unbeschränkt auf den Abschluss des Lesevorgangs wartet.

Für die Anwender sind die normalen Symptome das unerwartete Hängen von Prozessen, die normalerweise ohne Issue abgeschlossen werden. Diese Prozesse werden nach einem Neustart des CA Process Automation-Koordinationsrechners erwartungsgemäß abgeschlossen.  Dies kann einen kleinen Teil der Prozesse oder alle ausgeführten Prozesse betreffen. Es besteht kein Zusammenhang mit der Betriebszeit des Koordinationsrechners und kann kurz nach einem Neustart oder nach Tagen, Wochen oder Monaten einwandfreier Koordinationsrechnerfunktion auftreten.

Dieses Problem wurde nur in Umgebungen beobachtet, die hohe Volumes an CA Process Automation-Prozessen ausführen. In den meisten Umgebungen, in denen "E1000 NIC" installiert ist, ist das Problem nie aufgetreten, oder es ist so selten aufgetreten, dass es nicht entdeckt wurde.

Lösung:

Dieses Problem ist sehr schwierig zu bestätigen. Wenn dieses Problem auftritt, wird der CA Process Automation-Thread oft auf einem Socket-Lesevorgang blockiert, und es werden keine relevanten Fehler in die Protokolldateien geschrieben. Die Bestätigung des Problems erfordert das Überprüfen von mehreren Java-Thread-Speicherauszügen, die beim Auftreten dieses Problems aufgezeichnet werden, um zu bestätigen, dass der Operator bei einem Socket-Lesevorgang blockiert wird.

Wenn Fehler im Zusammenhang mit diesem Problem beobachtet werden, werden häufig generische Verbindungsfehler angezeigt, die andere berechtigte und nicht verwandte Ursachen haben könnten. Folgendes Beispiel:

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)

. . . und so weiter.

In diesen Fällen ist Identifizierung des Problems vorläufig, und andere Gründe für Kommunikationsfehler müssen ausgeschlossen werden.   

Häufige Prozessfehler oder ein wiederholbarer Fehler eines individuellen Operators oder von Operatoren zeigen wahrscheinlich andere nicht verwandte Probleme innerhalb des Prozessdesigns oder der Koordinationsrechnerfunktion an.

Bei Sites, wo dieses Problem bestätigt wurde, wird die Neukonfiguration des VMWare-Servers von einem "E1000 Network Interface Card"-Treiber auf einen "VMXnet-3 NIC"-Treiber als wirksame Minimierung des Problems angesehen. 

CA Technologies zögert, dies als vollständige Lösung zu deklarieren, da die Incident-Rate sehr gering ist und der Zeitraum zwischen den Vorkommen (auch mit "E1000 NIC") sehr lang sein kann.    

Wenn eine Überprüfung des Issues vor dem Durchführen dieser Änderung erforderlich ist, kontaktieren Sie den Support, um die Protokollierung und Java-Thread-Speicherauszüge einzurichten, die erforderlich sind, um die Fehlerbehebung für diesen bestimmten Issue durchzuführen.