Projet

Général

Profil

Actions

Bug #1278

fermé

Impossible de créer une gallerie d'images : plantage de silverpeas

Ajouté par Anonyme il y a plus de 13 ans. Mis à jour il y a plus de 13 ans.

Statut:
Closed
Priorité:
Immediate
Assigné à:
Début:
09/11/2010
Echéance:
% réalisé:

100%

Temps estimé:
Navigateur:
Firefox 3.x
Votre version de Silverpeas:
Unknown
Système d'exploitation:
Votre base de données:
MS SQL Server
Livraison en TEST:
Livraison en PROD:

Description

Je précise ici le contexte d'exécution car les bonnes valeurs ne figurent pas parmi les options de saisie de l'anomalie :
- Silverpeas Version : 5.4-SNAPSHOT (disponible sur repository Maven au 09/11/2010)
- Operating System : Windows Server 2003 64 bits
- Database : MS SQL Server 2005 64 bits
- JDK : Sun Java 1.6.0_22 64 bits
- JBoss Version : 4.0.3

Sur le serveur d'intégration pour le projet ADEF Résidences, actuellement en 5.4-SNAPSHOT, http://adef.oevo.com/ (voir espace du projet sur l'extranet Silverpeas pour les accès), si dans un espace, on souhaite créer une instance du composant Gallery, après avoir valider les paramètres de configuration, Silverpeas ne répond plus, la fenêtre reste scotchée...

Après vérification, on s'aperçoit que le processus java s'est arrêté brutalement. Le fichier traces.txt contient le seul message suivant :
09/11/10-21:03:45,968 - FATAL : WA2,CMP,Test,0,1

Pas d'autres logs visibles.

Mis à jour par Nicolas Eysseric il y a plus de 13 ans

  • Statut changé de New à Feedback

Je ne reproduis pas le problème avec les sources téléchargées ce soir.
Quels sont les paramètres spécifiés lors de l'instanciation ?

Mis à jour par Anonyme il y a plus de 13 ans

Tous paramètres : j'ai essayé avec plusieurs cas, y compris avec les paramètres par défaut proposés...

Attention, cela ne se produit, mais se produit systématiquement, que dans l'environnement spécifié c'est à dire sous Windows 2003 en 64 bits (ce n'est pas XP, ni Seven, et c'est en 64 bits) et sous SQL Server 2005 en 64 bits...
Cela ne se produit pas pour un composant de type Petites annonces par exemple.

Mis à jour par Anonyme il y a plus de 13 ans

  • Priorité changé de Normal à Immediate

Je viens de réessayer avec Windows Server 2003 (32 bits cette fois) + SQL Server 2005 et je retrouve le même problème. Cette fois Java ne plante pas mais le dialogue de création de galerie reste scotché et rien ne se passe.

Dans traces.txt, j'ai ceci après création de deux espaces et une tentative de création d'une galerie.

22/11/10-03:26:58,875 - FATAL : WA1,SP,ADEF Résidences,0,1
22/11/10-03:27:03,125 - FATAL : WA2,SP,Communication,0,1
22/11/10-03:28:29,953 - FATAL : WA2,CMP,Photothèque,0,1

On peut y accéder sur http://adef.oevo.com/ (Login SilverAdmin/AlgonisADEF), et en TSE sur l'adresse : adef.oevo.com:3496 (mdp Administrateur classique de silverpeas)

URGENT : ADEF Résidences (nous allons partir sur une base 5.4)

Mis à jour par Nicolas Eysseric il y a plus de 13 ans

  • Assigné à mis à Miguel Moquillon

Mis à jour par Miguel Moquillon il y a plus de 13 ans

  • Statut changé de Feedback à Resolved
  • % réalisé changé de 0 à 100

Le problème provenait de la politique de gestion des transactions dans MS SQLServer (pessimistic locking ?) qui fait qu'une requête, même en lecture, reste bloquée sur une table verrouillée (en l'occurrence ici SB_Node_Node) par une autre transaction. Le résultat est qu'au bout d'un certain temps (assez long), un time out était levé et la connexion à la base de donnée s'en trouvait fermée pouvant aboutir ainsi à un comportement évasif de l'application.
Ceci est arrivé parce que, tandis qu'une connexion était ouverte pour l'instanciation du composant Gallery, une autre connexion vers la base de donnée a été ouverte et qu'au travers de celle-ci une tentative de lecture se faisait sur la table SB_Node_Node qui avait été au préalablement verrouillée lors de la première connexion. Avec les SGBDR plus sérieux (Oracles, PostgreSQL), ce problème n'était pas apparu dû fait de leur gestion plus intelligente des transactions.

Mis à jour par Miguel Moquillon il y a plus de 13 ans

Le problème a été réglé en plaçant la requête de lecture vers la table SB_Node_Node, lors de l'instanciation d'un composant, dans la transaction principale (alors qu'auparavant elle était lancée au travers d'une autre connexion !).
(Note : l'ouverture de la nouvelle connexion se faisait dans la méthode getNextId() de DBUtil.)

Mis à jour par Nicolas Eysseric il y a plus de 13 ans

  • Statut changé de Resolved à Closed
  • Version cible mis à Version 5.4
Actions

Formats disponibles : Atom PDF