Discussion :

[Targan]

Bonjour,

Je suis nouveau dans le développement web. Donc je m'excuse si c'est une question simple, et déjà posée à de multiples reprises.

Est ce que Tomcat crée un thread par session user ?

Par exemple, je crée une application web et la déploye sur tomcat.
Maintenant, lorsque plusieurs utilisateurs se connectent à l'application web, est ce que tomcat crée un nouveau thread par utilisateur ?
Si c'est le cas, je peux donc espérer créer de nouveaux threads dans l'appli qui seront donc des enfants du thread créé par tomcat ?
Est ce que les données au niveau de la session restent synchronisées entre les threads ?

Merci.

[tchize_]

c'est un thread par requête HTTP (c'est donc indépendant de la session). Il n'y a pas de lock sur la session, si plusieurs requetes http arrivent simultanément pour la même session, et qu'elle modifient toutes le même objet de la session, le résultat sera aléatoire.

Vous pouvez créer vos propres thread, mais ce n'est pas recommandé en J2EE (mais parfois on est bien obligé )

[Targan]

J'ai beaucoup de mal à comprendre le fonctionnement des serveurs d'appli.

On a le serveur d'appli.
On a une appli qui est déployée (et donc une fois lancée qui à son propre thread / serveur (?)).

Ensuite, y a un thread (par requete HTTP) qui arrive au serveur. Comment se fait le lien entre la requete et l'appli alors (et par rapport aux données déjà instanciées) ? la requête serait un thread enfant de l'appli ?

Et les filters interviennent où dans tout cela ?

(petite parenthèse)
J'ai beaucoup de mal à appréhender tout cela.
Et je pose toutes ces questions, d'une part histoire de comprendre comment fonctionne une appli J2EE, mais c'est aussi en rapport avec le framework logback pour faire des logs / user. (Cf post dans logging).

Je voudrais faire un SiftAppender, pour une création "dynamique" de FileAppender pour faire un log / user. La valeur du user étant renseignée dans un MDC.

Mon problème est de comprendre comment les sessions user sont gérées, et si je me retrouve avec un thread / user et donc un MDC / user ou si cela reste un MDC commun. A priori cela reste un MDC commun au vu de votre réponse........

[tchize_]

l'application déployée, a priori, n'a pas de thread propre. tous les threads appartiennent au conteneur. En très gros, en cas de requete http, le conteneur va faire ceci:

Code x :

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

1
2
3
4
5
6
analyser la requete http
localiser la webapp associée
récupérer dans la webapp l'instance de Servlet qui correspond à la demande
construite les objet httpserlvetrequest et httpservletresponse
faire servlet.service(request,response);
fin de la requete, on libère le thread

Pour ce qui est d'associer des données au thread courant, ça se fait. Pour cela il faut implémenter un servletrequestlistener ou un filter. Ceux-ci recoivent la main au début de la requete http, et à la fin. Il peuvent donc service à initialiser et nettoyer des données en mémoire, fonction par exemple de l'utilisateur courant.

[Targan]

J'avoue que je suis paumé.

Je débarque sans connaissance sur une appli en architecture MVC utilisant un peu de spring, et beaucoup de Zk (qui est à la base surtout un framework pour faire de l'ajax mais qui au final est utilisé de partout, même pour faire les interfaces web classiques).

Bref du coup, je ne comprends pas grand chose à l'ordre d'execution des elements, ni à la gestion des threads.

En gros, cette appli a un web.xml qui declare un applicationContext.xml initialisant (via spring) un controleur.
Ce controleur sert au démarrage de l'appli pour récupérer un certains nombre d'infos d'environnement.

Ensuite, j'ai un fichier de config XXX-servlet.xml qui lui définit des mappings entre des pages html et des controleurs.

Au démarrage d'une session utilisateur, y a une jsp appelée qui renvoie sur une page html elle même gérée par un controleur.
De là, on en détermine les infos d'une class "User" qui servira au logger pour la création d'un log spécifique à cet utilisateur.

"En théorie", d'après vos explications, ainsi que la doc de Logback, par un filter il serait possible de mettre à jour le MDC avec la valeur utile de la class User (récupérée de la session), et en fin de requête libérer le MDC pour éviter tout conflit et ainsi ajuster le MDC en fonction du USER qui execute la requete.

Or, après de multiples tests, cela ne fonctionne pas.....j'ai tenté ceci dans le filter :

Code :

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

1
2
3
4
5
6
7
8
 
MDC.put("user", userid);
 
try {
    filterChain.doFilter();
} finally {
    MDC.remove("user");
}

Soit mon fichier de log n'est jamais crée....pourtant j'ai fait afficher dans la console la liste des valeurs du MDC après le put, et ma valeur y est bien insérée ; soit il est créé mais avec une valeur par défaut définit dans le fichier de config de logback comme si le remove se faisait "trop tôt".

Bref, je ne pige pas l'enchainement....il semblerait que l'architecture MVC telle qu'elle est utilisée dans cette appli n'est pas "conforme" pour une utilisation du filter et du MDC.

Par contre, si dans le code, je fais des puts, trace et remove enchainé, cela fonctionne parfaitement (et heureusement :p).

Donc je pensais que mon souci était cette histoire de gestion multithread/monothread par rapport au MDC, et donc qu'il y avait des conflits entre les sessions user executées.

Des idées sur le fait que le filter ne fonctionne point ? :p

Merci.

[tchize_]

vous avez mappé comment votre filter?