Project

General

Profile

Actions

Bug #1278

closed

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

Added by Philippe Bazart about 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Immediate
Start date:
11/09/2010
Due date:
% Done:

100%

Estimated time:
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.

Actions #1

Updated by Nicolas Eysseric about 11 years ago

  • Status changed from New to 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 ?

Actions #2

Updated by Philippe Bazart about 11 years ago

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.

Actions #3

Updated by Philippe Bazart about 11 years ago

  • Priority changed from Normal to 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)

Actions #4

Updated by Nicolas Eysseric about 11 years ago

  • Assignee set to Miguel Moquillon
Actions #5

Updated by Miguel Moquillon about 11 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 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.

Actions #6

Updated by Miguel Moquillon about 11 years ago

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.)

Actions #7

Updated by Nicolas Eysseric about 11 years ago

  • Status changed from Resolved to Closed
  • Target version set to Version 5.4
Actions

Also available in: Atom PDF