[trace, ASP 1.1] Fichier de trace trop gros ? comment l'éffacer ?
1 réponse
Christian
àJ'ai une appli ASP.NET 1.1 qui utilise uin fichier de trace :
Initialisation dans le Global.asax.cs :
Trace.Listeners.Add(new TextWriterTraceListener(File.AppendText(filename)));
Puis écriture par : Trace.WriteLine("blabla");
J'ai constaté la chose suivante :
Après plusieurs semaines de fonctionnement le fichier de Trace se met
subitement a ne plus évoluer (plus aucune trace écrite à l'intérieur),
pourtant l'application est utilisée. Je ne voit aucun message d'erreur. A ce
stade le fichier fait plus de 2Go.
Quelqu'un a-t-il une explication ? Y a t il une taille limite ?
Pour régler ponctuellement le pb :
- je fait une copie de sauvegarde du fichier de trace
- j'édite le fichier de trace , supprime son continue et j'essaye de le
sauver : Echec car l'OS me dit que ce fichier est déjà en court d'utilisation.
Un arrêt du service de publication Web ne débloque pas le fichier.
Pour m'en sortir je fais la chose suivante.
- Je passe le service de publication web en mode manuel et je reboote le
serveur
- au redémarrage je peux effectuer ma manip et me reptrouver avec un fichier
de trace de 1Ko
- je repasse le service en mode automatique et je le redemarre
- Il recommence alors à se remplir correctement
N'y a-t- il pas une méthode plus propre pour pouvoir accéder au fichier et
le vider de son contenu ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Arnaud CLERET
Bonsoir,
Normalement, l'arrêt de IIS devrait suffir à enlever les lock posés par le listener de trace.
Pour corriger le problème et contourner la limitation du framework .Net sur la gestion des fichiers traces, vous pouvez développer une couche intermediaire. Cette couche exposerait des méthode de type WriteError, WriteWarning ... et contrôlerait la taille du fichier afin de ne pas dépasser une taille limite.
Plus propre et plus adapté au framework .Net vous pouvez écrire un nouveau listener dérivant de TraceListener et surcharger la méthode Write().
Dans les deux cas, ces solutions vous permettent de ne plus intervenir sur votre serveur pour contrôler la taille des fichiers traces. D'autant plus que la purge peut être implémenté dans le même processus que celui de contrôle de la taille du fichier.
-- arno - http://www.dotnetguru2.org/acleret/
"Christian" a écrit :
àJ'ai une appli ASP.NET 1.1 qui utilise uin fichier de trace :
Initialisation dans le Global.asax.cs : Trace.Listeners.Add(new TextWriterTraceListener(File.AppendText(filename)));
Puis écriture par : Trace.WriteLine("blabla");
J'ai constaté la chose suivante : Après plusieurs semaines de fonctionnement le fichier de Trace se met subitement a ne plus évoluer (plus aucune trace écrite à l'intérieur), pourtant l'application est utilisée. Je ne voit aucun message d'erreur. A ce stade le fichier fait plus de 2Go.
Quelqu'un a-t-il une explication ? Y a t il une taille limite ?
Pour régler ponctuellement le pb : - je fait une copie de sauvegarde du fichier de trace - j'édite le fichier de trace , supprime son continue et j'essaye de le sauver : Echec car l'OS me dit que ce fichier est déjà en court d'utilisation.
Un arrêt du service de publication Web ne débloque pas le fichier. Pour m'en sortir je fais la chose suivante. - Je passe le service de publication web en mode manuel et je reboote le serveur - au redémarrage je peux effectuer ma manip et me reptrouver avec un fichier de trace de 1Ko - je repasse le service en mode automatique et je le redemarre - Il recommence alors à se remplir correctement
N'y a-t- il pas une méthode plus propre pour pouvoir accéder au fichier et le vider de son contenu ?
Merci,
Christian
Bonsoir,
Normalement, l'arrêt de IIS devrait suffir à enlever les lock posés par le
listener de trace.
Pour corriger le problème et contourner la limitation du framework .Net sur
la gestion des fichiers traces, vous pouvez développer une couche
intermediaire. Cette couche exposerait des méthode de type WriteError,
WriteWarning ... et contrôlerait la taille du fichier afin de ne pas dépasser
une taille limite.
Plus propre et plus adapté au framework .Net vous pouvez écrire un nouveau
listener dérivant de TraceListener et surcharger la méthode Write().
Dans les deux cas, ces solutions vous permettent de ne plus intervenir sur
votre serveur pour contrôler la taille des fichiers traces. D'autant plus que
la purge peut être implémenté dans le même processus que celui de contrôle de
la taille du fichier.
--
arno - http://www.dotnetguru2.org/acleret/
"Christian" a écrit :
àJ'ai une appli ASP.NET 1.1 qui utilise uin fichier de trace :
Initialisation dans le Global.asax.cs :
Trace.Listeners.Add(new TextWriterTraceListener(File.AppendText(filename)));
Puis écriture par : Trace.WriteLine("blabla");
J'ai constaté la chose suivante :
Après plusieurs semaines de fonctionnement le fichier de Trace se met
subitement a ne plus évoluer (plus aucune trace écrite à l'intérieur),
pourtant l'application est utilisée. Je ne voit aucun message d'erreur. A ce
stade le fichier fait plus de 2Go.
Quelqu'un a-t-il une explication ? Y a t il une taille limite ?
Pour régler ponctuellement le pb :
- je fait une copie de sauvegarde du fichier de trace
- j'édite le fichier de trace , supprime son continue et j'essaye de le
sauver : Echec car l'OS me dit que ce fichier est déjà en court d'utilisation.
Un arrêt du service de publication Web ne débloque pas le fichier.
Pour m'en sortir je fais la chose suivante.
- Je passe le service de publication web en mode manuel et je reboote le
serveur
- au redémarrage je peux effectuer ma manip et me reptrouver avec un fichier
de trace de 1Ko
- je repasse le service en mode automatique et je le redemarre
- Il recommence alors à se remplir correctement
N'y a-t- il pas une méthode plus propre pour pouvoir accéder au fichier et
le vider de son contenu ?
Normalement, l'arrêt de IIS devrait suffir à enlever les lock posés par le listener de trace.
Pour corriger le problème et contourner la limitation du framework .Net sur la gestion des fichiers traces, vous pouvez développer une couche intermediaire. Cette couche exposerait des méthode de type WriteError, WriteWarning ... et contrôlerait la taille du fichier afin de ne pas dépasser une taille limite.
Plus propre et plus adapté au framework .Net vous pouvez écrire un nouveau listener dérivant de TraceListener et surcharger la méthode Write().
Dans les deux cas, ces solutions vous permettent de ne plus intervenir sur votre serveur pour contrôler la taille des fichiers traces. D'autant plus que la purge peut être implémenté dans le même processus que celui de contrôle de la taille du fichier.
-- arno - http://www.dotnetguru2.org/acleret/
"Christian" a écrit :
àJ'ai une appli ASP.NET 1.1 qui utilise uin fichier de trace :
Initialisation dans le Global.asax.cs : Trace.Listeners.Add(new TextWriterTraceListener(File.AppendText(filename)));
Puis écriture par : Trace.WriteLine("blabla");
J'ai constaté la chose suivante : Après plusieurs semaines de fonctionnement le fichier de Trace se met subitement a ne plus évoluer (plus aucune trace écrite à l'intérieur), pourtant l'application est utilisée. Je ne voit aucun message d'erreur. A ce stade le fichier fait plus de 2Go.
Quelqu'un a-t-il une explication ? Y a t il une taille limite ?
Pour régler ponctuellement le pb : - je fait une copie de sauvegarde du fichier de trace - j'édite le fichier de trace , supprime son continue et j'essaye de le sauver : Echec car l'OS me dit que ce fichier est déjà en court d'utilisation.
Un arrêt du service de publication Web ne débloque pas le fichier. Pour m'en sortir je fais la chose suivante. - Je passe le service de publication web en mode manuel et je reboote le serveur - au redémarrage je peux effectuer ma manip et me reptrouver avec un fichier de trace de 1Ko - je repasse le service en mode automatique et je le redemarre - Il recommence alors à se remplir correctement
N'y a-t- il pas une méthode plus propre pour pouvoir accéder au fichier et le vider de son contenu ?
