Merci à tous, pour ces réponses et accompagnements et bon week end.
]]>ruizsebastien> Mais si c'est un problème vis à vis de l'application client, pourquoi çà ne s'était pas produit depuis ? Je tiens à informer quand même que historiquement, on a migré la base de données de postgresql 8.4 windows vers postgresql 9.4 linux il y avait environ 1 moi de cela.
Et ce problème de connectivité à la base s'est apparu depuis ses 2 dernières semaines.
Donc ça sent quand même le problème dans votre serveur d'application.
Comme indiqué par le message d'erreur, jouez avec le timeout.
Voici les extraits de logs juste avant < 2017-04-24 06:23:19.473 EAT >
< 2017-04-24 06:02:00.357 EAT >DÉTAIL: paramètres : $1 = 'DECISION_VALIDATION_XML', $2 = '80'
< 2017-04-24 06:02:00.365 EAT >LOG: durée : 5.087 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.365 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_GR_PAR', $2 = '80'
< 2017-04-24 06:02:00.379 EAT >LOG: durée : 11.021 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.379 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_META_IDENTIFICATOIRES', $2 = '80'
< 2017-04-24 06:02:00.392 EAT >LOG: durée : 9.677 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.392 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_META_DECISION_ANTERIEURE', $2 = '80'
< 2017-04-24 06:02:00.403 EAT >LOG: durée : 8.403 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.403 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_META_SECONDAIRE', $2 = '80'
< 2017-04-24 06:02:00.415 EAT >LOG: durée : 8.810 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.415 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ANONYMISATION_MANUAL', $2 = '80'
< 2017-04-24 06:02:00.426 EAT >LOG: durée : 8.572 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.426 EAT >DÉTAIL: paramètres : $1 = 'DECISION_SELECTION_ANONYMISATION', $2 = '80'
< 2017-04-24 06:02:00.437 EAT >LOG: durée : 9.289 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.437 EAT >DÉTAIL: paramètres : $1 = 'DECISION_LAYERS_CONTROL', $2 = '80'
< 2017-04-24 06:02:00.455 EAT >LOG: durée : 3.159 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.455 EAT >DÉTAIL: paramètres : $1 = 'REPRISE_CORR_COUCHES', $2 = '80'
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.474 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
Le message d'erreur exact au niveau de l'appli client lors de l'authentification est celui ci:
>>> Erreur: La base de données n'est pas en ligne ? [A timeout has occured. If you were establishing a connection, increase Timeout value in ConnectionString or in your NpgsqlCommandobject]
ruizsebastien> L'application utilise glassfish qui elle utilise le pilote jdbc pour se connecter à la base postgresql.
Sinon, il existe une tache planifiée lancée chaque samedi soir pour faire une reindexation de la base. Est ce que cela pourrait en être la source du problème? Je ne pense pas en tout cas vu que je n'ai pas le souvenir d'avoir eu ce genre de problème avant. Et normalement, la reindexation devrait déjà être bien finie avant le Lundi matin.
]]>Comment se connecte l'application ?
Car le message d'erreur laisse à penser que la déconnexion est faite par le client (Connexion ré-initialisée par le correspondant).
Avez-vous essayé de vous connecter avec psql au moment où l'application n'arrivait plus à se connecter ?
]]>Nous utilisons postgresql-9.4 sur un serveur linux. Dans ce SGBD existe la base de données postgres, et notre base de données "X" qui elle est utilisée par une application.
Nous constatons que cela fait 2 fois successives environ à chaque début de semaine que notre base de données "X" devient inaccessible. Je m'explique:
- le service postgresql est en marche
- la base postgres sous postgresql est accessible
- Cependant, notre base de données "X" sous postgresql, elle, est inaccessible
Après redémarrage du service postgresql, apparemment le problème est règlé et notre base de données "X" redevient accessible à nouveau.
Pour l'instant, pour contourner le problème nous envisageons de programmer le redémarrage du service à chaque fin de semaine.
Toutefois, auriez vous une explication à ce qui peut être la cause de ce problème ? Et quelle solution optimale serait la bonne ?
Nous avions remarqué que le log mentionne des informations comme suit:
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.474 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
Aviez vous une idée d'où pourrait provenir le problème ?
Merci déjà de l'attention que vous porteriez à ce sujet.
Dans l'attente de vous lire
]]>