[HB/MySQL]SocketException après longue inactivité

Version imprimable

Bonjour à tous,

j'utilise hibernate et je suis face à un petit problème. Au bout d'un certain temps d'inactivité sur mon site (disons, une dizaine d'heures), chaque nouvelle tentative de connexion me renvoie l'exception suivante:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
08:33:38,890 ERROR JDBCExceptionReporter:78 - Communications link failure due to underlying exception: 
 
** BEGIN NESTED EXCEPTION ** 
 
java.net.SocketException
MESSAGE: Software caused connection abort: socket write error
 
STACKTRACE:
 
java.net.SocketException: Software caused connection abort: socket write error
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(Unknown Source)
    at java.net.SocketOutputStream.write(Unknown Source)
    at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
    at java.io.BufferedOutputStream.flush(Unknown Source)
    ...
** END NESTED EXCEPTION **
Last packet sent to the server was 0 ms ago.

Pourtant, j'utilise bien un pool de connexion autre que celui par défaut (dbcp). Voici une partie de mon fichier hibernate.cfg.xml:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
        <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
        <property name="hibernate.connection.url">jdbc:mysql://localhost/test?autoReconnect=true</property>
        <property name="hibernate.connection.username">root</property>
        <property name="hibernate.connection.password">root</property>
        <property name="hibernate.connection.pool_size">10</property>
        <property name="transaction.auto_close_session">true</property>
        <property name="show_sql">false</property>
        <property name="dialect">org.hibernate.dialect.MySQLInnoDBDialect</property>
 
        <property name="org.hibernate.tool.hbm2ddl">true</property>
        <property name="hibernate.hbm2ddl.auto">update</property>
        <property name="myeclipse.connection.profile">MySQL local</property>
        <property name="connection.url">jdbc:mysql://localhost/test?autoReconnect=true</property>
        <property name="connection.username">****</property>
        <property name="connection.password">****</property>
        <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
 
        <!--### Apache DBCP Connection Pool ###-->
        <!--connection pool-->
        <property name="hibernate.dbcp.maxActive">10</property>
        <property name="hibernate.dbcp.whenExhaustedAction">1</property>
        <property name="hibernate.dbcp.maxWait">20000</property>
        <property name="hibernate.dbcp.maxIdle">10</property>
 
        <!-- prepared statement cache-->
        <property name="hibernate.dbcp.ps.maxActive">10</property>
        <property name="hibernate.dbcp.ps.whenExhaustedAction">1</property>
        <property name="hibernate.dbcp.ps.maxWait">20000</property>
        <property name="hibernate.dbcp.ps.maxIdle">10</property>
 
        <!-- optional query to validate pooled connections:-->
        <property name="hibernate.dbcp.validationQuery">select 1</property>
        <property name="hibernate.dbcp.testOnBorrow">true</property>
        <property name="hibernate.dbcp.testOnReturn">true</property>
        <!--### END OF Apache DBCP Connection Pool ###-->

Pourtant, cette configuration semble n'avoir aucune influence....

Une idée ?

05/12/2007, 15h58
OButterlin
Le problème vient de la configuration de mySQL.
Par défaut, au bout de 8h (me semble t-il), il y a un timeout sur la connexion.

Je ne suis pas sûr que ça fonctionne, mais essaye de rajouter la ligne suivante dans le fichier my.ini :
Code:

1 2 3 4 5 6 ... [client] port=3306 connect-timeout=864000 ...
Là, ça ferait 10 jours de délai d'inactivité...

A+
05/12/2007, 16h11
BugFactory

Mais ça ne fait que reporter le problème, non?

Autres solutions :
Intercepter cette exception grâce à un try catch, fermer l'ancienne connexion et en ouvrir une autre.

Créer un timer quand vous vous connectez. A chaque requête, le remettre à zéro. Au bout d'un temps d'inactivité trop long, fermer la session. La réouvrir pour la requête suivante.

Fermer la connexion quand on n'en a plus besoin.
05/12/2007, 16h14
Pill_S

hum... j'ai pas vraiment de contrôle sur ce fichier... je suis chez un hébergeur
05/12/2007, 16h23
Pill_S

Citation:

Envoyé par BugFactory

Autres solutions :

Waou.... niveau bidouillage c'est pas mal du tout, mais dans la vraie vie ça me ferait mal de faire un truc pareil...

Et puis, fermer la session, c'est déjà fait... Je la ferme à chaque fin de transaction... C'est apparament la connexion du pool qui finit dans les choux...

Malgré le "autoReconnect=true"...
05/12/2007, 17h07
OButterlin

Citation:

Envoyé par BugFactory

Intercepter cette exception grâce à un try catch, fermer l'ancienne connexion et en ouvrir une autre.

Ça ne règle pas le problème, du-moins si c'est le même que celui que j'avais.
Le problème est plus loin, tu n'arrives même plus à ouvrir une nouvelle connexion une fois que c'est arrivé, comme s'il y avait un tuyau entre le pool de connexion et la db, le tuyau est là, mais y a plus personne au bout !

Je sais qu'il y avait déjà un post sur le forum java à ce sujet, mais je n'arrive plus à le retrouver.
A+

Les gestionnaires de pool de connexion des serveurs d'application comme weblogic, peuvent être configurés simplement de manière à tester périodiquement la validité des Connection et les recréer automatiquement si elles sont invalidés.
Tu peux configurer ton pool pour avoir un fonctionnement analogue. D'ailleurs cela semble être le cas.
Code:

1 2 3 4 5  <property name="hibernate.dbcp.validationQuery">select 1</property> <property name="hibernate.dbcp.testOnBorrow">true</property> <property name="hibernate.dbcp.testOnReturn">true</property> 
Par contre ta requete de validation me semble supecte : select 1
Cela n'est à priori pas un requete sql valide
Remplace là par une requete qui fonctionne dans ton appli et qui est EXTREMENT RAPIDE.

13/12/2007, 12h27
Gardyen

select 1 est parfaitement valide, elle renvoie 1 et c'est la plus rapide qui soit, même pas besoin de connaître le nom de la base/table à tester...
13/12/2007, 12h51
Pill_S

Citation:

Envoyé par Gardyen

select 1 est parfaitement valide, elle renvoie 1 et c'est la plus rapide qui soit, même pas besoin de connaître le nom de la base/table à tester...

+1
le problème n'est pas la requête... d'ailleurs je ne sais pas d'où vient le problème, il n'est toujours pas résolu... Mais comme on est encore en phase de dév, ce n'est pas vraiment urgent...
Si quelqu'un a une idée, elle est plus que bienvenue

;)
21/12/2007, 15h17
né-ti

T'es tu penché sur les pools de connexion C3PO ?
21/12/2007, 15h20
Pill_S

Pas encore... j'ai juste essayé avec dbcp.

Mais c'est vrai que je pourrais tester ;)
23/12/2007, 13h14
Pill_S

Apparement ça marche beaucoup mieux avec C3PO ;)

et il me semble avoir lu quelque part qu'il faut configurer un data source dans tomcat pour pouvoir utiliser DBCP (chose que je n'avais pas fait)

cela semble résolu en tout cas :)