La chose n'est pas compliquée du tout, mais c'est juste pour éviter de la réimplémenter si ça existe déja dans log4j :
Un système qui permet de loguer le temps qu'a pris telle ou telle action. Genre, un système permettant de signaler à log4j qu'on entame une action à "chronomètrer", puis que la durée soit dispo lors du prochain message logué. Finalement, pendant que j'écris ça, je me dis qu'il y a uand même peu de chance que ça existe déja. Tant pis, je poste quand même, on verra bien !

bin ca existe peut etre mais je ne vois pas le rapport avec log4j. Log4j ca logue et pis c'est tout
 
Pq pas demander à SWING d'envoyer un mail en meme temps que tu appuyes sur le joli boutton "send"  
 

 
Ben, ça peut faire partie de la notion de logue le truc que je décris. log4j il est bien capable de récupérer la date système par exemple, on est pas obligé de la récupérer, et de la lui passer entant que donnée à loguer.
Enfin bon, t'as peut être raison en fait. C'est peut être hors contexte pour log4j...

 
bin c'est parce qu'il doit retenir un état et au niveau identification c'est pas le top  Et dans ton pattern tu définirais ca comment?
 
de toutes manière le système "je note le temps, je fais des brols puis je renote le temps et je fais la différence" ca sucks parce que la période peut etre influencé par tout un tas de facteur, surtout si ton appli est multithreadée

 
Ouais, c'est ça le problème, c'est qua dans le pattern, c'est pas définissable. Mais finalement, avec log4j, on peut mettre des trucs dans un pattern qui sont renseignés "en dur" dans le code (avec les MDC par exemple). Donc dans le pattern, on pourrait juste mettre nue valeur dynamique (genre {counterTime}).
Mais en fait, j'pense que je vais simplement utiliser le MDC : Faire une classe "Chrono", et renseigner moi même une valeur {counterTime}.
 

 
Ben, si, c'est exactement ce que je veux : pour que les utilisateurs de mon appli (web-app) puissent faire des stats, sur le temps que prend tel ou tel truc.

 
fort bien et ma réponse: "ca sucks" pour les raisons suscitées. Des stats sur des données fausses ce ne sont pas des stats désolé.

 
Tu connais un autre moyen de mesurer le temps ????
Et puis ils sont pas à la miliseconde près. Ils veulent savoir si le truc prend 1 minute en moyenne ou 10 secondes...

 
Temps processeur en mesurant le process de la JVM et pas un truc global à la machine
 

 
tu as réfléchis aux points suivants:
 
- un process lourd, genre backup est en cours de traitement sur ton serveur
- tu as 30 clients connectés sur ta machien
- la machine swap parce qu'il y a tel ou tel truc qui tourne
 
va donner un résultat différent que si tu as ta fonctionnalité qui tourne toute seul sur la machine sans client sans rien.
 
Maintenant si il veulent savoir si ca prend 10 secondes ou 1 minute, y a pas besoin de compter, une estimation humaine suffit amplement        

 
Non, vraiment, j'comprends pas ce que tu veux dire...
Si la machine swap ou autre chose, le client attendra plus longtemps pour avoir sa réponse. Et le temps que je mesurerai avce le différentiel des heures système sera lpus long aussi. Je comprend pas ce qui peut faire que ces données soient fausses. Que la machie swap uo non, l'heure systèmm avance bien d'une secondes toutes les secondes, alors ou est le pb ?
 
Et le process de la JVM, tu mesures ça comment !?

Bon c'est quoi que tu veux mesurer à la fin, le temps de réponse de ta fonction ou bien le temps de réponse en fonction de l'environnement?
 
L'idée c'est : si la machine swap à cause d'un truc qui n'a rien a voir avec tes brols, bin ta web app sera plus lente mais ca ne sera pas véritablement ta faute. Donc les stats risquent d'etre faussée.
 
Maintenant si tu veux faire des stats "10 sec ou 1min" qui sont en plus dépendant de ce qui tourne sur la machine, ne fais pas de stats ... Appuie sur submit et regarde ta montre ca ira plus vite

 
Mais c'est le temps de réponse global, pas de ma fonction en particulier. Permettre au client d'optimiser son environnement. De constater si mon appli est ralentie quand ils font des sauvegardes par exemple.
Je veux le temps entre le moment ou le gars clique sur le submit, et le moment ou il a sa réponse (sans compter le temps de transfert HTTP, évidement. ça, ça serait encore une autre histoire...).

ce que je tente de t'expliquer c'est que ca ne va rien t'apprendre de savoir si ton appli est plus lente de 22 sec si ca swap de 24Mo.   Parce que tu ne sauras qui est responsable de quoi ...
 
Enfin bon

 
ça, c'est pas mon PB. J'vais pas enquêter chez les clients pour savoir ce qui peut faire que ma web-app est plus ou moins rapide.
Moi, je leur fournis de quoi savoir si les conditions sont bonnes pour mon appli. Après, si ça va pas, à eux de voir s'il faut une machine plus puissante, un serveur en plus, ou autre chose...

 
euh bon ok.

 
Merci quand même.
 
Et pour mon autre topic du moment :
http://forum.hardware.fr/forum2.ph [...] ubcat=#bas
 
En fait t'as jamais utilisé ce fameux MDC ?

 
non j'ai lu l'explication du gars et pis voilà

 
ça te parait juste ce qu'il à marqué ? Les données que j'met dans le MDC ne risquent pas de se mélanger entre les clients d'après toi ?

 
bin si ton objet est l'identifiant de ton client y a pas de raison non?

 
...quel objet ? (j'ai l'impression de tourner en rond des fois !)

 
bin ca c'est toi qui décide patate ... Si tu associes un MDC à ton object client dans ta session HTTP par exemple, bin le tour est joué (à ce que j'ai compris bien sur)

 
Mais, il est pas question d'"associer" un MDC à un objet. C'est une sorte de "hashtable de thread". Et je vais pas mettre mon objet "visiteur" dans le MDC. il faut y mettre les objets dont le "toString()" m'interresse...

l'idée est de récupérer le MDC sur base de l'objet (ici le client) et envoyer donc les logs de cette manière