Bug #8243
fermé
Requête bloquée dans la table sc_resources_reservation
100%
Description
Bonjour,
Une requête est régulièrement bloquée dans la table d'activité de Postgres:
datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start | state_change | waiting | state | query
-------+----------------------+-------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
16387 | SilverpeasProduction | 9770 | 16385 | spuser | | 127.0.0.1 | | 49016 | 2016-09-15 10:34:38.052313+02 | | 2016-09-15 10:34:38.116701+02 | 2016-09-15 10:34:38.164741+02 | f | idle | select \r +
| | | | | | | | | | | | | | | sc_resources_reservation.id,\r +
| | | | | | | | | | | | | | | sc_resources_resource.name AS RESSOURCE, st_user.firstname AS PRENOM,\r +
| | | | | | | | | | | | | | | st_user.lastname AS NOM,\r +
| | | | | | | | | | | | | | | evenement AS OBJET, \r +
| | | | | | | | | | | | | | | TIMESTAMP 'epoch' + (to_number(begindate, '9999999999999')+3600000+3600000) * INTERVAL '0.001 second' AS DATEDEBUT,\r +
| | | | | | | | | | | | | | | TIMESTAMP 'epoch' + (to_number(enddate, '9999999999999')+3600000+3600000) * INTERVAL '0.001 second' AS DATEFIN,\r +
| | | | | | | | | | | | | | | reason AS DESCRIPTION,\r +
| | | | | | | | | | | | | | | place AS LIEU \r +
| | | | | | | | | | | | | | | \r +
| | | | | | | | | | | | | | | from sc_resources_reservation,\r +
| | | | | | | | | | | | | | | st_user,\r +
| | | | | | | | | | | | | | | sc_resources_resource,\r +
| | | | | | | | | | | | | | | sc_resources_reservedresource\r +
| | | | | | | | | | | | | | | where \r +
| | | | | | | | | | | | | | | \r +
| | | | | | | | | | | | | | | sc_resources_reservation.instanceid='resourcesManager3137'\r +
| | | | | | | | | | | | | | | and sc_resources_resource.id=sc_resources_reservedresource.resourceid\r +
| | | | | | | | | | | | | | | and sc_resources_reservation.id=sc_resources_reservedresource.reservationid\r +
| | | | | | | | | | | | | | | and st_user.id=sc_resources_reservation.userid \r +
| | | | | | | | | | | | | | | and TIMESTAMP 'epoch' + (to_number(begindate, '9999999999999')+3600000) * INTERVAL '0.001 second' > (CURRENT_TIMESTAMP - interval '2 days')\r +
| | | | | | | | | | | | | | | \r +
| | | | | | | | | | | | | | | ORDER BY DATEDEBUT asc
Elle apparait souvent très peu de temps après un redémarrage du portail, sans doute dès la première consultation d'une ressource, et reste bloquée indéfiniment, jusqu'à ce qu'on ai besoin de redémarrer le portail.
Le portail semble bien fonctionner, même avec cette requête de bloquée, mais elle peut-être la cause de dysfonctionnement déjà ou pas encore déclaré.
Cordialement.
Mis à jour par David Lesimple il y a plus de 8 ans
- Tracker changé de Bug à Support
- Statut changé de New à Feedback
Ces requetes ont été saisies dans des applications connecteurJDBC. Je ne pense pas que la requête en question (avec des \r) soient syntaxiquement corrects, en tout cas, cela ne passe pas dans pgAdmin.
Mis à jour par Emmanuel GRANGE il y a plus de 8 ans
Effectivement, il s'agit bien du connecteur JDBC.
Ce connecteur nous permet d'extraire les données pour avoir des statistiques pour les resourcesManager, puisqu'il ne le propose pas en natif (Feature ?)
Mais le connecteur nous donne bien les résultats, bien que la requête reste bloquée.
N'y aurait-il pas un bug plutôt dans le connecteur JDBC ?
Mis à jour par David Lesimple il y a environ 8 ans
Possible.. je te suggère de modifier toutes les requêtes pour qu'elle se terminent par un ;
et qu'il n'y ait pas de saut de ligne vide.
Mis à jour par Emmanuel GRANGE il y a environ 8 ans
D'accord.
Est-il possible de le faire sans accéder à l'application (lance automatiquement la requête qui se bloque) ?
Mis à jour par David Lesimple il y a environ 8 ans
possible oui, mais c'est moins facile. Je conseille de le faire via l'IHM.
Mis à jour par Emmanuel GRANGE il y a environ 8 ans
- Projet changé de Resources Manager à JDBC Connector
Sauf que pour chaque application, je vais bloquer une requête.
Puis-je le faire directement sous Postgres, sans redémarrer le portail ?
Mis à jour par Emmanuel GRANGE il y a environ 8 ans
J'ai retiré sur le portail de Production et de Test tous les retours chariot des requêtes des connecteurs JDBC, mais même sans cela, les requêtes restent bloqués dans la pile d'exécution de postgresql.
Il semble que le problème soit plus profond que ça.
Mis à jour par David Lesimple il y a environ 8 ans
La requete est bonne et est bien executée par Postgresql, elle reste là car il semble que le client (l'application connecteurJDBC) ne l'a pas fermée.
Ce n'est pas gênant outre mesure.
Mis à jour par David Lesimple il y a environ 8 ans
- Statut changé de Feedback à Closed
- % réalisé changé de 0 à 100
Après vérification dans le code, je confirme la remarque précédente, elle n'est pas bloquée, la connexion reste ouverte tant que le portail tourne.
C'est le fonctionnement normal.
Mis à jour par Emmanuel GRANGE il y a environ 8 ans
- % réalisé changé de 100 à 0
Cela veut dire qu'à chaque fois qu'on accède à cette application, les requêtes vont rester bloquées !
Si plusieurs personnes bloquent plusieurs fois la même requête, on risque une saturation de Postgresql et un plantage du portail (même si j'en conviens, il y a de la marge).
Pour moi, c'est un comportement à risque.
Dans ce cas, je préfère ne plus utiliser cette application.
Mis à jour par David Lesimple il y a environ 8 ans
- Tracker changé de Support à Bug
- Statut changé de Closed à New
- Version cible mis à Version 5.15.4
- Votre base de données mis à Toutes
Emmanuel GRANGE a écrit :
Cela veut dire qu'à chaque fois qu'on accède à cette application, les requêtes vont rester bloquées !
Si plusieurs personnes bloquent plusieurs fois la même requête, on risque une saturation de Postgresql et un plantage du portail (même si j'en conviens, il y a de la marge).Pour moi, c'est un comportement à risque.
Dans ce cas, je préfère ne plus utiliser cette application.
En fait, une connexion BD est ouverte pour chaque utilisateur qui accède à cette application et cette connexion BD reste disponible pour cet utilisateur et tant qu'il est connecté.
Le problème est que si l'utilisateur se reconnecte, une autre connexion BD est ouverte..
On peut donc vite faire monter le nombre de connexions BD réservées pour cette application (surtout si on a plusieurs connecteurJDBC).
Je le passe en bug.
Si tu le souhaites, un hot fix peut être réalisé facilement.
Mis à jour par Emmanuel GRANGE il y a environ 8 ans
Super, bonne nouvelle.
Par contre, ce n'est pas très urgent, donc pas besoin d'un hot fix.
Mis à jour par Miguel Moquillon il y a environ 8 ans
- Statut changé de Feedback à In progress...
- Assigné à mis à Miguel Moquillon
Mis à jour par Miguel Moquillon il y a environ 8 ans
- Statut changé de In progress... à Resolved
- % réalisé changé de 0 à 100
Mis à jour par Miguel Moquillon il y a environ 8 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Miguel Moquillon il y a environ 8 ans
- Statut changé de Integration in progress... à V6 pending
Mis à jour par Miguel Moquillon il y a environ 8 ans
- Statut changé de V6 pending à Closed