Discussion :

[luna007]

Bonjour,

Je voudrais savoir s'il y a un parseur thread safe ?

J'ai une page sur une application web qui parse, via jdom, un flux XML résultat d'une requête envoyée à un système exterieure. le problème c'est que en effectuant des tests de charges sur cette page, on s'est rendu compte que dès qu'il y a plus qu'un utilisateur, la jsp commence à donner des exceptions. en cherchant, on a trouvé que jdom n'est pas thread safe. nous avons testé jaxp avec dom, et aussi xerces avec Dom, on a eu le même problème. dès qu'on teste avec 2 utilisateurs concurrents on a des problèmes.

Est ce que quelqu'un a déjà travaillé avec un parseur qui est multithread ?
sinon comment on fait pour résoudre ce problème ?

Merci d'avance pour votre aide.

[deltree]

Ce n'est pas le parseur qui doit être Thread-safe, ce sont les variables de ton programme (i.e. l'environnement mémoire en prog parallèle).

- Si tous tes Threads ont leur propres variables: pas de soucis
- Si 2 Thread partagent un même environnement mémoire: variable, Objet, Class avec attributs statiques: il y a un problème: il faut synchronizer les accès en écriture de façon intelligente (cad qui ne fait pas de dead-lock)

Il faudrait voir le source de ton programme pour qu'on se fasse une idée, il y a surement un petite erreur de conception.

[luna007]

Ce n'est pas le parseur qui doit être Thread-safe, ce sont les variables de ton programme (i.e. l'environnement mémoire en prog parallèle).

- Si tous tes Threads ont leur propres variables: pas de soucis
- Si 2 Thread partagent un même environnement mémoire: variable, Objet, Class avec attributs statiques: il y a un problème: il faut synchronizer les accès en écriture de façon intelligente (cad qui ne fait pas de dead-lock)

Il faudrait voir le source de ton programme pour qu'on se fasse une idée, il y a surement un petite erreur de conception.

Tout d'abord, merci pour votre rapide réponse.

En fait. on a une jsp de recherche, dont l'action renvoi vers une autre jsp qui rend les résultats. cette dernière intérroge un système extérieure. le système rend comme réponse un flux XML. la jsp resultats se charge de parser ce flux et de formater le résultat sous forme HTML.

Comme j'ai dit, nous avons utilisé au départ Jdom. voilà un petit bout du code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
<%!static URL url;
static HttpURLConnection http;
private static final SAXBuilder builder = new SAXBuilder();
private static Document Doc = null;
 
public static void setDoc(InputStream inputStream) throws IOException, JDOMException {
	Doc = builder.build(inputStream);
}
%>
 
...
 
<%
...
InputStream inputStream = resultatExterne(requete);
setDoc(inputStream);		
Element root = Doc.getRootElement();
List Rubrique = root.getChildren("rubriques");
......
%>

Ensuite, nous avons utilisé Jaxp avec DOM, voilà un bout de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
<%
....
InputStream inputStream = resultatExterne(requete);
 
		DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
Document Doc = docBuilder.parse(inputStream);
 
//root
Node root=Doc.getDocumentElement();
 
//récupération des rubriques
NodeList rubriques= Doc.getElementsByTagName("rubriques");
...
%>

Je note que ma jsp ne fait que lire le fichier XML, pas d'écriture.
plusieurs utilisateurs devront pouvoir intérroger la jsp sans problème. je ne sais pas si on peut dire dans ce cas qu'ils partagent les mêmes variables ?

Sinon, comment pourrais-je implémenter la synchronisation dont vous venez de parler ?

Merci d'avance pour l'aide

[thelvin]

je ne sais pas si on peut dire dans ce cas qu'ils partagent les mêmes variables ?

Si vous mettez un bout de code statique, oui, on peut dire qu'ils partagent les mêmes variables, car ils le font.

Sinon, non.

Effectivement, l'exemple avec un scriplet statique risque de poser problème du fait que SAXBuilder n'est pas thread-safe. Il suffit de le rendre non-static, quel intérêt ?

Dans le deuxième exemple, où il n'y a pas de static, il ne semble pas y avoir de soucis de thread-safety.

[luna007]

Si vous mettez un bout de code statique, oui, on peut dire qu'ils partagent les mêmes variables, car ils le font.

Sinon, non.

Effectivement, l'exemple avec un scriplet statique risque de poser problème du fait que SAXBuilder n'est pas thread-safe. Il suffit de le rendre non-static, quel intérêt ?

Nous l'avions fait, mais ça donne toujours des exceptions quand on fait des tests de charges avec plus d'un utilisateur.

Dans le deuxième exemple, où il n'y a pas de static, il ne semble pas y avoir de soucis de thread-safety.

pourtant ça donne toujours des exceptions dès que nous configurons le test à plus d'un utilisateur à la fois.

Est ce qu'il y a quelque chose à ajouter au code, pour que ça fonctionne en multi-thread?

merci d'avance.

[thelvin]

C'est peut-être simplement autre chose, qui fait des exceptions quand vous testez avec plus d'un utilisateur à la fois ?

C'est un peu ce qu'implique ce que j'ai dit.

[deltree]

Si vous mettez un bout de code statique, oui, on peut dire qu'ils partagent les mêmes variables, car ils le font.

Sinon, non.

Effectivement, l'exemple avec un scriplet statique risque de poser problème du fait que SAXBuilder n'est pas thread-safe. Il suffit de le rendre non-static, quel intérêt ?

Dans le deuxième exemple, où il n'y a pas de static, il ne semble pas y avoir de soucis de thread-safety.

c'est ça.

Les variables accédées en static ne sont pas en lecture seule, elle contiennent ton tout parsing: une bonne méthode pour s'en apercevoir est de représenter tes 2 Thread plus la variable commune sur un diagramme de séquence.

Pour le 2ème exemple: en théorie: si 2 Thread ne partagent ni le même contexte d'exécution, ni les mêmes variables ils sont indépendants et ce n'est pas un problème de synchro, c'est la façon la plus simple pour faire du multi-threading. Si c'est vraiment un problème de synchro, ce n'est pas ton parser mais une autre variable qui est impliquée.

Il faudrait voir l'exception pour s'en assurer.

2-3 choses:
.Ce serait plus facile à débugger si tu mettait ton code dans une servlet et pas une JSP.

.Si vraiment tu veut faire de la synchro, les mots-clefs utilisés sont "synchronized (mutex) { ... }" wait notify: mieux vaut suivre les tutoriels pour s'en servir. Mais il ne faut pas perdre de vue que si tu synchronise la variable static, tout tes Thread vont s'enchainer en séquence, autant ne pas faire de multithreading !

.Il y a aussi SAX si tu a des problèmes de perfs

.est-ce que tu a vraiment besoin de parser l'xml à chaque appel?

[luna007]

C'est peut-être simplement autre chose, qui fait des exceptions quand vous testez avec plus d'un utilisateur à la fois ?

C'est un peu ce qu'implique ce que j'ai dit.

c'est ça.

Les variables accédées en static ne sont pas en lecture seule, elle contiennent ton tout parsing: une bonne méthode pour s'en apercevoir est de représenter tes 2 Thread plus la variable commune sur un diagramme de séquence.

Nous laissons tombé le 1er exemple avec des variables static pour utiliser plutôt le code sur le 2ème exemple.

Pour le 2ème exemple: en théorie: si 2 Thread ne partagent ni le même contexte d'exécution, ni les mêmes variables ils sont indépendants et ce n'est pas un problème de synchro, c'est la façon la plus simple pour faire du multi-threading. Si c'est vraiment un problème de synchro, ce n'est pas ton parser mais une autre variable qui est impliquée.

Il faudrait voir l'exception pour s'en assurer.

Il me reste un cas à vérifier pour m'assurer que ce n'est pas autre chose comme vous dites et comme dit thelvin

.est-ce que tu a vraiment besoin de parser l'xml à chaque appel?

oui en fait j'ai besoin de parser à chaque appel, car à chaque appel c'est un flux XML différent que je parse (le flux XML résultat d'une requête à un système externe.)

Merci de votre aide. je vais faire un dernier test pour être sûr que ce n'est pas un autre problème et je vous tiens au courant de ce que ça donne.

[luna007]

Je vous remercie de votre aide. effectivement il y avait une autre variable statique de la fonction de récupération des données externes.

Le problème est résolu.

Merci encore