JDBC de SQL Server restablecimiento de la conexión de error: Sólo en Amazon EC2

Question

Contexto: La nube

Tenemos una aplicación web basada en Java que normalmente los anfitriones en nuestros propios servidores. Recientemente utilizamos la nube de Amazon Web Services (AWS EC2) para alojar una instancia.

Esta "configuración de la nube" coincide con nuestra típica "in situ" de configuración: un servidor para el servidor de aplicaciones, otro servidor para el servidor de base de datos. (Varios servidores de aplicaciones apuntan al mismo servidor de base de datos)

El problema En esta configuración la nube, recibimos intermitente "restablecimiento de conexión por errores de pares" entre la base de datos y el controlador JDBC, donde al (aparentemente) intervalos aleatorios y en puntos al azar en la base de código, la conexión de la base de datos falla.

Éstos son algunos extractos de error para el registro de

Seguimiento de la pila Ejemplo 1:

at com.participate.pe.genericdisplay.client.taglib.GenDisplayViewTag.doStartTag(GenDisplayViewTag.java:77) 
    ... 75 more 
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed. 
    at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:170) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:304) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.getMetaData(SQLServerConnection.java:1734) 
    at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:354) 

Seguimiento de la pila Ejemplo 2

at java.lang.Thread.run(Thread.java:619) 
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1355) 
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1532) 
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3274) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4437) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4389) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1457) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4026) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1416) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1462) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1610) 
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:429) 

Medio Ambiente Técnica

• Jboss 4.2.2.GA (Jboss en la Web 2.0/Tomcat 6)
• MSSQL 2005 2.0 controlador JDBC

Algunos puntos

• Tenemos nunca se ven este problema en nuestro propio entorno (es decir, propios centros de datos) ejecutando la aplicación durante varios años
• Esto me llevó a concluir que "algo gracioso está sucediendo con el entorno de red de Amazon". Puedo estar equivocado/falta algo/etc.
• Este problema solo ocurre con nuestra aplicación. Tenemos otras aplicaciones java y php que no han tenido este problema. La otra aplicación Java utiliza un controlador JDBC diferente (jtds, que yo sepa)
• no parece como un simple tiempo de espera de conexión

Preguntas

-Tiene Alguien ha visto esto antes? -Si es un "problema conocido" de EC2, ¿podemos configurar nuestro camino para resolver el problema (es decir, asegurarse de que todo esté en su propia subred o nube privada virtual (vpc)? -¿Alguna configuración del controlador jdbc para superar este problema?

** actualización ** he ampliado y aumentado la recompensa por esta pregunta

en poco más de información: los dos servidores virtuales (base de datos y servidor de aplicaciones) estaban en diferentes subredes - es decir, un salto. entre los dos servidores.

En un entorno no en la nube, tenemos "cero saltos" entre los dos servidores.

Nuestros administradores de alojamiento dijeron que no teníamos control sobre las subredes de nuestras instancias EC2. Esto me hizo preguntarme si la nube privada virtual ayudaría.

gracias de antemano

se

Answer 1

Solo una palabra de precaución sobre las funciones de grupo de conexión/DBCP para mitigar el problema: cuanto más habilite 'testOnBorrow' y otras características, más podrá introducir latencia u otros cambios de rendimiento en el sistema. No sé si DBCP todavía hace esto o no, pero hace algunos años generaría consultas de prueba reales para probar la conexión (pila completa, respuestas de bases de datos) y no solo en la capa de red. El enlace anterior de Brian trae recuerdos horribles de principios de la década de 2000 sobre la lógica de verificación de los alrededores para la gestión de la conexión JDBC.

De todos modos, es difícil realmente causa raíz de esto, aparte de reunir pruebas y eliminar el 'aparentemente al azar' a un conjunto específico de condiciones:

• Se podría tratar de lanzar un rastro Wireshark/PCAP , encuentre cuándo sucede y envíe los resultados a Amazon y Microsoft para ver si pueden desencadenarlo

• Puede intentar lo anterior con ciertos arneses de prueba para aislar el problema (pruebas de JMeter para aumentar la concurrencia), Rebote la conexión de red, observe si hay recuperación, etc.

• Puede probar versiones alternativas de SQL Server para descontar un error del controlador SQL Server/JDBC que se ha solucionado desde entonces.

• Si DNS se utiliza en las cadenas de conexión, puede utilizar las direcciones IP para validar cuestiones nslookup

No soy un experto en SQL Server, pero otra ruta para la investigación podría estar dentro del dominio de productos relacionados - p.ej ver si alguien experimentó problemas similares con TFS/Sharepoint (por ejemplo, http://nickhoggard.wordpress.com/2009/12/07/further-experiences-with-tfs-2010-beta-2-on-amazon-ec2/)

Answer 2

No estoy seguro si esto está relacionado o no. Experimentamos algo similar con una aplicación que estábamos ejecutando en el entorno EC2. El mismo síntoma es que la conexión a la base de datos se cerraría intermitentemente. Estábamos usando el controlador MSSQL 1.2. Además, veríamos los errores generalmente después de un retraso o un tiempo de inactividad con la conexión. Nuestra suposición (nunca probada) fue que algo en la capa de red estaba cerrando la conexión y el cliente no la detectaba, por lo que se volvió obsoleta.

Pudimos evitarlo porque estábamos utilizando grupos de conexiones de commons, y la piscina recreaba la conexión en caso de error. Eventualmente movimos la aplicación de EC2 y no volvimos a ver el problema.

Answer 3

He visto este problema tanto en el entorno EC2 como en el entorno de Windows Azure. Creo que la lógica de reintento de conexión debe ser una parte estándar de su diseño cuando se trabaja en un entorno informático distribuido.

This article es para SQL Azure, pero creo que se aplica igualmente a EC2 y a todos los controladores.

Answer 4

También puedo confirmar que esto sucede y activará una investigación de menor prioridad ya que no es crítica para la producción.
Nuestros servidores de producción se encuentran en nuestro centro de datos. Usamos computadoras portátiles desarrolladoras para ejecutar nuestras aplicaciones. Ninguno de estos tiene este problema una vez que configuramos los tiempos de espera del grupo de conexiones c3p0 y el período de prueba (consulte el artículo: http://www.codefin.net/2007/05/hibernate-and-mysql-connection-timeouts.html).

Sin embargo, tenemos un servidor de etapas de desarrollo que está en EC2 y de hecho sucede allí. Si encuentro algo que parece funcionar, devolveré el ping. Además, estoy usando mysql. Veo que está usando MS SQL Server por lo que se encuentra entre los proveedores de bases de datos.