J'ai construit une application et l'ai déployée localement ... et elle fonctionnait parfaitement. Je l'ai déployé sur un serveur distant et j'ai commencé à obtenir l'exception mentionnée dans la ligne d'objet. Ce n'est pas à cause d'un problème de pare-feu.
J'ai changé mon hibernate.xml
pour me connecter via mon adresse IP plutôt que localhost et maintenant je reçois les mêmes délais d'expiration sur mon application déployée localement. Je reçois cette erreur lorsque l'application continue à fonctionner pendant plus d'une journée.
Je n'effectue aucune opération après avoir effectué des transactions ou clôturé des sessions moi-même. J'utilise les propriétés suivantes dans hibernate.cfg.xml
<property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.url">jdbc:mysql://myremotehost:3306/akp</property>
<property name="hibernate.connection.username">root</property>
<property name="hibernate.connection.password">root</property>
<property name="hibernate.show_sql">false</property>
<property name="hibernate.current_session_context_class">thread</property>
<property name="hibernate.query.factory_class">org.hibernate.hql.ast.ASTQueryTranslatorFactory</property>
Causée par: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: aucune opération autorisée après la fermeture de la connexion. La connexion a été implicitement fermée par le pilote.
Détaillé:
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.Connection was implicitly closed by the driver.
at Sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at Sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.Java:39)
at Sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.Java:27)
at Java.lang.reflect.Constructor.newInstance(Constructor.Java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.Java:409)
at com.mysql.jdbc.Util.getInstance(Util.Java:384)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.Java:1015)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.Java:989)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.Java:984)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.Java:929)
at com.mysql.jdbc.ConnectionImpl.throwConnectionClosedException(ConnectionImpl.Java:1193)
at com.mysql.jdbc.ConnectionImpl.checkClosed(ConnectionImpl.Java:1180)
at com.mysql.jdbc.ConnectionImpl.prepareStatement(ConnectionImpl.Java:4137)
at com.mysql.jdbc.ConnectionImpl.prepareStatement(ConnectionImpl.Java:4103)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.Java:505)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.Java:423)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.Java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.Java:1547)
at org.hibernate.loader.Loader.doQuery(Loader.Java:673)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.Java:236)
at org.hibernate.loader.Loader.doList(Loader.Java:2220)
... 36 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 34,247,052 milliseconds ago. The last packet sent successfully to the server was 34,247,052 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.
at Sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at Sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.Java:39)
at Sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.Java:27)
at Java.lang.reflect.Constructor.newInstance(Constructor.Java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.Java:409)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.Java:1118)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.Java:3321)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.Java:1940)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.Java:2113)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.Java:2568)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.Java:2113)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.Java:2275)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.Java:186)
at org.hibernate.loader.Loader.getResultSet(Loader.Java:1787)
at org.hibernate.loader.Loader.doQuery(Loader.Java:674)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.Java:236)
at org.hibernate.loader.Loader.doList(Loader.Java:2220)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.Java:2104)
at org.hibernate.loader.Loader.list(Loader.Java:2099)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.Java:94)
at org.hibernate.impl.SessionImpl.list(SessionImpl.Java:1569)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.Java:283)
at com.xyz.abc.DAO.GenericHibernateDAO.findByField(GenericHibernateDAO.Java:119)
at com.xyz.abc.DAO.JobDAO.getJobsByLdap(JobDAO.Java:115)
at com.xyz.abc.business.Jcr.getMyruns(Jcr.Java:272)
at com.xyz.abc.business.abcService.getMyruns(abcService.Java:54)
at Sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:25)
at Java.lang.reflect.Method.invoke(Method.Java:597)
at org.Apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.Java:194)
at org.Apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.Java:102)
at org.Apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.Java:40)
at org.Apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.Java:114)
at org.Apache.axis2.engine.AxisEngine.receive(AxisEngine.Java:173)
at org.Apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.Java:173)
at org.Apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.Java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.Java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.Java:722)
at org.Apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.Java:304)
at org.Apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.Java:208)
at org.Apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.Java:240)
at org.Apache.catalina.core.StandardContextValve.invoke(StandardContextValve.Java:203)
at org.Apache.catalina.core.StandardHostValve.invoke(StandardHostValve.Java:164)
at org.Apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.Java:108)
at org.Apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.Java:118)
at org.Apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.Java:379)
at org.Apache.coyote.http11.Http11Processor.process(Http11Processor.Java:242)
at org.Apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.Java:259)
at org.Apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.Java:237)
... 4 more
Caused by: Java.net.SocketException: Software caused connection abort: socket write error
Quelqu'un a-t-il une idée de ce qui pourrait causer ce comportement?
EDIT: Maintenant, j'utilise ce qui suit dans mon fichier hibernate.cfg.xml. Est-ce correct?
<property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.url">jdbc:mysql://localhost:3306/xyz</property>
<property name="hibernate.connection.username">root</property>
<property name="hibernate.connection.password">root</property>
<property name="hibernate.show_sql">false</property>
<property name="hibernate.current_session_context_class">thread</property>
<property name="hibernate.query.factory_class">org.hibernate.hql.ast.ASTQueryTranslatorFactory</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.max_size">20</property>
<!-- <property name="hibernate.c3p0.max_size">1800</property>-->
<property name="hibernate.c3p0.max_statements">50</property>
<property name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="c3p0.max_statements">0</property>
<property name="c3p0.maxIdleTimeExcessConnections">3600</property>
<property name="c3p0.idleConnectionTestPeriod">3600</property>
<property name="c3p0.maxIdleTime">3600</property>
Comme @swanliu l'a souligné, cela est dû à une mauvaise connexion.
Cependant, avant d’ajuster le timing du serveur et le délai d’expiration du client, je voudrais d’abord essayer d’utiliser une meilleure stratégie de regroupement des connexions.
_ {Hibernate lui-même admet que sa stratégie de regroupement de connexions est minimale}
L'algorithme de mise en commun des connexions d'Hibernate est cependant assez rudimentaire. Il est destiné à vous aider à démarrer et n'est pas destiné à être utilisé dans un système de production, ou même pour des performances essai. Vous devez utiliser un pool tiers pour optimiser les performances et stabilité. Il suffit de remplacer la propriété hibernate.connection.pool_size avec les paramètres spécifiques du pool de connexion. Cela désactivera celui d'Hibernate piscine interne. Par exemple, vous voudrez peut-être utiliser c3p0 .
Comme indiqué dans la référence: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html
Personnellement, j'utilise C3P0
. Cependant, il existe d'autres alternatives, dont DBCP
.
Check-out
Vous trouverez ci-dessous une configuration minimale de C3P0 utilisée dans mon application:
<property name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="c3p0.acquire_increment">1</property>
<property name="c3p0.idle_test_period">100</property> <!-- seconds -->
<property name="c3p0.max_size">100</property>
<property name="c3p0.max_statements">0</property>
<property name="c3p0.min_size">10</property>
<property name="c3p0.timeout">1800</property> <!-- seconds -->
Par défaut, les pools n'expireront jamais les connexions. Si vous le souhaitez Les connexions doivent expirer dans le temps afin de conserver la "fraîcheur", définissez maxIdleTime et/ou maxConnectionAge. maxIdleTime définit combien secondes, une connexion doit être utilisée avant d’être utilisée tiré de la piscine. maxConnectionAge force le pool à supprimer tout Les connexions acquises à partir de la base de données sont plus nombreuses que l'ensemble nombre de secondes dans le passé .
Comme indiqué dans la référence:http://www.mchange.com/projects/c3p0/index.html#managing_pool_size
Modifier:
J'ai mis à jour le fichier de configuration ( Référence ), car je venais de copier-coller celui de mon projet plus tôt . Le délai d'attente devrait idéalement résoudre le problème. Si cela ne fonctionne pas, une solution chère que je pense pouvoir examiner:
Créez un fichier «c3p0.properties» qui doit figurer à la racine du chemin de classe (c’est-à-dire qu’il n’est pas possible de le remplacer pour des parties particulières de l’application). ( Référence )
# c3p0.properties
c3p0.testConnectionOnCheckout=true
Avec cette configuration, chaque connexion est testée avant d'être utilisée. Cela pourrait toutefois affecter les performances du site.
MySQL a implicitement fermé la connexion à la base de données parce que la connexion était inactive depuis trop longtemps (34 247 052 millisecondes ≈ 9,5 heures) . Si votre programme récupère alors une mauvaise connexion dans le pool de connexions à l'origine du MySQLNonTransientConnectionException: No operations allowed after connection closed
.
MySQL suggère:
Vous devez envisager expirer et/ou tester la validité de la connexion avant de l'utiliser dans votre application, en augmentant les valeurs configurées par le serveur pour les délais d'expiration du client, ou en utilisant la propriété de connexion Connector/J
autoReconnect=true
pour éviter cela. problème.
Si vous ne voulez pas utiliser le pool de connexions (vous êtes sûr que votre application n'a qu'une seule connexion), vous pouvez le faire. Si la connexion tombe, vous devez établir une nouvelle méthode à un appel .openSession () à la place. getCurrentSession ()
Par exemple:
SessionFactory sf = null;
// get session factory
// ...
//
Session session = null;
try {
session = sessionFactory.getCurrentSession();
} catch (HibernateException ex) {
session = sessionFactory.openSession();
}
Si vous utilisez Mysql, vous pouvez définir autoReconnect property:
<property name="hibernate.connection.url">jdbc:mysql://127.0.0.1/database?autoReconnect=true</property>
J'espère que ça aide.
Assurez-vous que vous utilisez le dernier connecteur jdbc selon le mysql. Je faisais face à ce problème et lorsque j'ai remplacé mon ancien connecteur jdbc par le dernier, le problème a été résolu.
Vous pouvez télécharger le dernier pilote jdbc depuis https://dev.mysql.com/downloads/connector/j/
Sélectionnez Système d'exploitation indépendant de la plate-forme. Il va vous montrer deux options. Un comme tar et un comme Zip. Téléchargez le fichier Zip et extrayez-le pour obtenir le fichier jar et remplacez-le par votre ancien connecteur.
Ce n'est pas seulement pour le cadre hibernate, il peut être utilisé avec n'importe quelle plate-forme nécessitant un connecteur jdbc.
Commencez par remplacer la dépendance MySQL comme indiqué ci-dessous
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-Java</artifactId>
<version>5.1.44</version>
</dependency>
Une erreur indiquant "Authentication plugin 'caching_sha2_password'" apparaîtra. Exécutez cette commande:
mysql -u root -p
ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';