Síntoma:
Las causas raíces de este problema son fallos poco frecuentes y esporádicos de E/S del socket que pueden dejar el software de llamada a la espera de forma indefinida para que se complete una lectura.
Desde el punto de vista del usuario, el síntoma más habitual sería el bloqueo inesperado de procesos que normalmente se completan sin problemas, que se reanudan y completan como estaba previsto tras el reinicio del orquestador de CA Process Automation. Esto puede afectar a un pequeño subconjunto de procesos o a todos los procesos en ejecución. No existe correlación alguna con el tiempo de actividad del orquestador y puede manifestarse poco después del reinicio o al cabo de varios días, semanas o meses; de lo contrario, se trata de una funcionalidad del orquestador sin problemas.
Este problema únicamente se ha observado en entornos que ejecutan grandes volúmenes de procesos de CA Process Automation. En la mayoría de los entornos en los que se instala la tarjeta NIC E1000, el problema nunca se produce o lo hace con tan poca frecuencia que no se ha detectado.
Solución:
Este problema resulta muy difícil de confirmar. Si se produce, normalmente, el subproceso de CA Process Automation se bloquea durante la lectura de un socket y no se escriben errores relevantes en los archivos de registro. La confirmación del problema requiere la revisión de una serie de volcados de subprocesos de Java que se han realizado mientras se producía este problema para confirmar que el operador se ha bloqueado durante la lectura de un socket.
Cuando se detectan errores relacionados con este problema, suelen indicar errores de conexión genéricos que pueden deberse a otras causas justificadas e inconexas. A continuación, se muestra un ejemplo de esto:
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.
En estos casos la identificación del problema es provisional y deben excluirse otras causas del fallo de comunicación.
Un error de procesos frecuente o un fallo repetible de un operador individual o varios operadores indican que probablemente existan otros problemas inconexos en el diseño del proceso o la funcionalidad del orquestador.
En sitios en los que se ha confirmado este problema, la reconfiguración del servidor de VMWare de una tarjeta de interfaz de red E1000 a un controlador de NIC de VMXnet-3 se considera una mitigación muy efectiva.
CA Technologies vacila a la hora de declararla como una solución completa, ya que la tasa de este incidente es muy poco frecuente y el intervalo entre las ocurrencias puede ser muy largo, incluso con la NIC E1000.
Si se requiere verificar la incidencia antes realizar este cambio, debe ponerse en contacto con soporte para obtener ayuda sobre la configuración del registro y los volcados de subprocesos de Java requeridos para verificar esta incidencia concreta y solucionar los problemas de esta.
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|