J'ai plusieurs processus fonctionnant simultanément que je souhaite me connecter au même fichier.
Nous utilisons la bibliothèque d'entreprise 4.1 Bloc d'application de journalisation (avec un J'ai essayé diverses choses, y compris appeler Les forums Entlib suggèrent d'utiliser MSMQ avec un service de distribution, mais ce n'est pas une option car MSMQ n'est pas autorisé à ma société.
Y a-t-il une autre manière que je peux vous connecter rapidement et facilement à partir de plusieurs threads / processus dans le même fichier? RollingflaTfileTraCelisener ), et cela fonctionne bien, mis à part le fait qu'il répeint un guide au nom du fichier journal lorsque deux processus essaient de Écrivez dans le fichier journal en même temps (une quirk de System.Diagnostics.textwriterTraCelistener Je crois).
logger.writer.dispose () après avoir écrit au fichier journal, mais ce n'est pas idéal pour effectuer un appel de blocage chaque fois qu'une entrée de journal est écrite. .
4 Réponses :
Entlib verrouille le fichier journal quand il l'écrit. Par conséquent, 2 processus ne peuvent pas écrire sur le même fichier journal.
Lorsque nous avons eu ce problème, que nous devions vous connecter à de nombreux endroits de différence, au même endroit, nous avons utilisé la journalisation de la base de données.
Si vous êtes à 100% bloqué dans un fichier texte, vous pouvez vous connecter à des fichiers journaux individuels, puis écrivez un programme pour fusionner ces fichiers.
Même 2 écouteurs de traces distincts dans le même processus ne peuvent pas se connecter au même fichier.
Ouais, la journalisation de la base de données n'est pas une option pour nous, nous n'en avons pas. Pour le moment, nous allons en effet avec des fichiers journaux individuels que nous fusionnons ensemble. Mais ce sera juste une solution de contournement à court terme.
Désolé de dire mais la réponse est non. Les tracelisteners de fichier verrouillent le fichier de sortie afin que seul un seul tracelisteneur puisse se connecter à un fichier.
Vous pouvez essayer d'autres écouteurs de trace qui ne sont pas basés sur des fichiers (par exemple la base de données, le journal des événements).
Une autre option que je peux penser serait d'écrire votre propre service de journalisation (hors processus) qui vous connecterait au fichier et accepterait les logements de logement. Ensuite, créez un écouteur de trace personnalisé qui envoie un message à votre service.
Ce n'est peut-être pas une bonne idée puisque vous auriez un peu de développement personnalisé, plus cela pourrait avoir une incidence sur la performance puisqu'il s'agit d'un appel hors processus. Fondamentalement, vous mettez en place votre propre service simplifié-pseudo-distributeur.
C'est la même conclusion que nous sommes venus aussi. À plus long terme, nous écrirons probablement un simple service de WCF Fire-and-Fouch pour la journalisation, il semble que la seule autre option fonctionnelle. Pitié cependant.
Je sais que c'est vieux, mais si vous êtes toujours curieux. Log4Net prend en charge cette suivante:
http://logging.apache.org/log4net/release/faq.html#How do I get multiple process to log to the same file?
Merci. Utiliser Log4Net sur ce projet n'était pas une option. Si c'était ma décision, je l'utiliserais certainement sur Entlib, la journalisation Entlib est trop balloise et difficile à comprendre.
Le problème se produit lorsque le pool d'applications recycle et permet de se chevaucher de threads. Le fil de fermeture est toujours ouvert et le nouveau thread obtient l'erreur. Essayez de désactiver le comportement de recyclage se chevauchant dans IIS ou créez votre propre version de l'auteur de texte.
Avez-vous eu une solution alternative? Peut-être utiliser MSMQ ?
@Kiquenet, ça fait si longtemps, je ne me souviens pas bien. Si j'essaie vraiment fort, je me souviens vaguement que nous avons fini par utiliser différents fichiers journaux pour différents processus pour contourner ce problème. Ce n'est pas idéal, mais nous voulions garder les choses simples.
Je pourrais ajouter si je devais choisir un cadre forestier maintenant, je resterais aussi loin que possible de la bibliothèque d'entreprises. C'est trop complexe, à la fois à utiliser et à configurer, et pas facilement extensible. J'irais probablement avec log4net ou Nlog .