Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'avais posé les questions qui suivent dans la partie General, n'ayant pas de réponse je repose mes questions dans ce forum (pour une 9.3 et jdbc4) :
1) Est-ce que la méthode setQueryTimeOut est implémentée ? Un test d'une valeur à 2 secondes semble ne pas fonctionner.
2) Si aucun timeout n'est donné quels sont les timeout que l'implémentation jdbc utilise ?
3) Lorsqu'un client perd le réseau (sur du WIFI) nous reconnectons la base (mais cela semble inutile car un executeQuery avec réseau stoppé semble attendre mais basé sur quel timeout ça on n'a pas trouvé) et nous avons eu le cas suivant : même avec un arrêt du poste clients les connexion restent ouvertes sur le serveur !!! Comment cela est-il possible ? Nous avons dû les détruire avec la méthode suivante :
SELECT pg_terminate_backend(procpid)
FROM (select procpid from pg_stat_activity WHERE datname = '<mabase>' AND usename='<user>'
order by backend_start
limit (select count(*)-1 from pg_stat_activity WHERE datname = '<mabase>'' AND usename='<user>' ) )
Cordialement
Hors ligne
Le timeout concerne le temps d'exécution. Si vous voulez le tester, essayez un appel à pg_sleep(10) par exemple.
Si vous avez des soucis réseaux, il faut plutôt voir du côté del a pile tcp du serveur, des équipements réseaux, ou des paramètres tcp_keepalives_*
Julien.
https://rjuju.github.io/
Hors ligne
Oui nous avons sûrement des problèmes réseau ... Mais ce qui nous chiffonne en réalité c'est que lorsque le client n'est plus connecté, on le voit toujours côté serveur postgresql. Et ça nous aimerions savoir 1) pourquoi ces connexions fantômes et 2) combien de temps ces connexions fantômes restent-elles d'où ma questions sur les timeout : lesquels et combien de temps ?
Ces connexions fantômes on les tue avec la commande sus-mentionnée.
En tout cas merci de ta réponse.
Hors ligne
Comme dit dans mon messages précédent, tout cela est conditionné à la configuration tcp du serveur. Sur la plupart des OS, le tcp_keepalive est positionné à 2h, donc le serveur mettra beaucoup de temps à s'en rendre compte. Configurer de manière plus aggressive selon vos besoin les paramètres tcp_keepalives_* de postgres devrait régler votre problème.
Julien.
https://rjuju.github.io/
Hors ligne
J'ai joué avec
/proc/sys/net/ipv4/tcp_keepalive_time -> 15 mn
/proc/sys/net/ipv4/tcp_keepalive_intvl -> 1 mn
/proc/sys/net/ipv4/tcp_keepalive_probes -> 9
Au bout de 15+9*1 mn j'ai toujours les connexions du côté serveur postgresql .... J'ai pas redémarré le serveur ni relancé postgresql. Donc à part forcer leur clôture via pg_terminate_backend je vois pas ce que je peux faire !
Hors ligne
Pages : 1
