conexiones rancio, validationQuery no soluciona

que estoy recibiendo las excepciones de conexión rancio MySQL JDBC temidas:conexiones rancio, validationQuery no soluciona

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed. 
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 243,263,541 milliseconds ago. The last packet sent successfully to the server was 243,263,541 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

Parece que todos están de acuerdo que este se fija mediante el uso de validationQuery + testOnBorrow, pero esto no es resolver el problema .

Estoy utilizando el siguiente software MySQL 5.1.41-3ubuntu12.10 Connector/J 5.1.18 Tomcat 6.0.24

aquí es cómo la conexión se define en server.xml, estamos utilizando el tomcat-dbcp para agrupar las conexiones.

<Resource 
     auth="Container" 
     driverClassName="com.mysql.jdbc.Driver" 
     factory="org.apache.commons.dbcp.BasicDataSourceFactory" 
     logAbandoned="true" 
     maxActive="75" 
     maxIdle="20" 
     maxWait="10000" 
     name="jdbc/jndiname" 
     password="password" 
     removeAbandoned="true" 
     removeAbandonedTimeout="60" 
     validationQuery="/* ping */SELECT 1" 
     testOnBorrow="true" 
     testOnReturn="true" 
     timeBetweenEvictionRunsMillis="10000" 
     testWhileIdle="true" 
     scope="Shareable" 
     type="javax.sql.DataSource" 
     url="jdbc:mysql://host:3306/schema" 
     username="username" />

Fuente

2012-01-30 user763648

¿En qué situación está obteniendo esas excepciones de conexión obsoleta? ¿Estás enviando una consulta en vivo, y ese es el resultado? ¿Usted acaba de crear la conexión JDBC como lo hizo con la consulta, o los está agarrando de un grupo de conexiones? – technocrat

Las excepciones de conexión ocurren todas las mañanas cuando un usuario se conecta a nuestra aplicación web por primera vez. Las conexiones provienen del conjunto Tomcat-DBCP. Podemos solucionar el problema reiniciando Tomcat todos los días, pero eso solo está ocultando el verdadero problema. – user763648

Cuando reinicia Tomcat, todo lo que hace es hacer que la agrupación de conexiones vuelva a establecerse por sí misma. ¿Crees que la solución a esto será la configuración de tomcat, la configuración de mysql o un cambio de código de grupo de tomcat-dbcp? Solo para saber en qué dirección buscar respuestas. – technocrat

podría comprobar la wait_timeout en el archivo my.cnf. El valor predeterminado es 28800 segundos u 8 horas. Tiene un máximo de 31536000 segundos o 365 días.

Para la primera excepción, tenga en cuenta: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException, en el pasado lo envolví en un bloque try/catch. En la captura, para esa excepción, tuve la conexión de reconexión, y luego volví a enviar la consulta. Al saber que no quería tener que hacer eso muy a menudo y aún mantener una conexión abierta, también aumenté el valor predeterminado de wait_timeout a algo razonable para mi aplicación.

Véase el Manual de referencia en: http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_wait_timeout

Fuente

2012-01-30 19:59:14 technocrat

Nuestro wait_timeout está configurado en los 28800 segundos predeterminados, pero preferimos corregir la causa del problema en lugar de simplemente reducir la frecuencia. – user763648

Al menos te dará un respiro hasta que puedas arreglarlo. Lo que ese valor está diciendo es lo siguiente: si mi conexión no se usa durante 28800 segundos, ¡finalícela! En su sistema, si su grupo Tomcat-DBCP no mantiene su conexión activa (como en una sentencia DDL o DML/query/insert/select ...) entonces MySQL terminará la conexión después de 8 horas, aunque tal vez aún no se dé cuenta. hasta que intente realizar dicho DDL/DML. ¿Puedes publicar el código donde configuraste el grupo de conexiones? Problema similar en MySQL: http://forums.mysql.com/read.php?39,501441,501692#msg-501692 – technocrat

He actualizado la pregunta para incluir nuestro atributo de conexión completo de server.xml. Toda nuestra lógica de base de datos se inicia desde la capa de Hibernate, hacia abajo a través de tomcat-dbcp al controlador Connector/J. – user763648

Su consulta validación es incorrecta. Elimine "seleccionar 1" y deje solo ping.

Fuente

2015-08-26 16:20:07 Mike

No es cierto, consulte http://dev.mysql.com/doc/connector-j/en/connector-j-usagenotes-j2ee-concepts-connection-pooling.html Para usar esta función, especifique una consulta de validación en su grupo de conexiones que comienza con/* ping */ 'protected static final String PING_MARKER ="/* ping */";' '...' 'if (sql.charAt (0) == '/') {' ' if (sql.startsWith (PING_MARKER)) {' ' doPingInstead(); ' '} ' – user763648

Basé mi respuesta en esto: https://dev.mysql.com/doc/connector-j /en/connector-j-usagenotes-tomcat.html El siguiente fragmento de código XML ilustra cómo seleccionar esta opción: validationQuery /* * mesa de ping/ Tenga en cuenta que/* * mesa de ping/ha de especificarse exactamente. – Mike

En my.cnf de su mysql, establezca las siguientes propiedades para un gran valor como 365 días -

wait_timeout = 31536000
interactive_timeout = 31536000

El valor de la sesión wait_timeout se inicializará con un valor global de wait_timeout para las conexiones no interactivos y con el valor global interactive_timeout para conexiones interactivas.

PS - Ambos valores están en segundos.

Fuente

2016-07-26 06:45:27

conexiones rancio, validationQuery no soluciona

Respuesta

Cuestiones relacionadas