запись нескольких процессов в один файл журнала - PullRequest
4 голосов
/ 10 марта 2009

Предполагается, что это упрощенное универсальное решение, хотя проблема в настоящее время связана с приложением IIS CGI, которое должно регистрировать временную шкалу событий (второе разрешение) для устранения неполадок в ситуации, когда более поздний запрос заканчивается в базе данных MySQL ДО предыдущий запрос!

Таким образом, все сводится к записи отладочных операторов в одном текстовом файле.

Я мог бы написать сервис, который управляет очередью, как предложено в этой теме: Ошибка записи в один файл в веб-сервисе в .NET но развертывание сервиса на каждой машине - это боль

или я мог бы использовать глобальный мьютекс, но для этого требовалось бы, чтобы каждый экземпляр открывал и закрывал файл для каждой записи

или я мог бы использовать базу данных, которая бы справилась с этим для меня, но нет смысла использовать базу данных, такую ​​как MySQL, чтобы попытаться решить проблему с временной шкалой. SQLite - еще одна возможность, но этот поток

http://www.perlmonks.org/?node_id=672403

Предполагает, что это не очень хороший выбор.

Я действительно ищу простой подход, такой же тупой, как запись в отдельные файлы для каждого процесса и их консолидация случайно с помощью запланированного приложения. Я не хочу чрезмерно проектировать это, ни тратить неделю, осуществляя это. Это нужно только время от времени.

Предложения

Ответы [ 5 ]

4 голосов
/ 10 марта 2009

Попробуйте сначала самое простое решение - каждая запись в журнал открывает и закрывает файл. Если у вас возникли проблемы с этим, которых, вероятно, нет, поищите другое решение.

3 голосов
/ 10 марта 2009

Вы можете использовать блокировку файлов. Заблокируйте файл для записи, напишите сообщение, разблокируйте.

1 голос
/ 10 марта 2009

Я бы также предложил какой-нибудь центральный логгер, который может вызываться каждым процессом асинхронно. Если обмен данными осуществляется по протоколу UDP, RPC или как-то еще, это будет деталь реализации.

1 голос
/ 10 марта 2009

Мое предложение - сохранить производительность, а затем подумать о асинхронном ведении журнала. Почему бы не отправить информацию из вашего журнала данных, используя UDP, на служебный порт прослушивания, а он записать в файл журнала.

0 голосов
/ 26 мая 2010

Даже если бы это был старый пост, кто-нибудь понял, почему не использовать следующую концепцию:

  1. Создание / открытие файла в режиме общего доступа FILE_SHARE_WRITE.
  2. Наличие именованного глобального мьютекса и его открытие.
  3. Когда требуется запись в файл, сначала заблокируйте мьютекс, а затем запишите в файл.

Любой ввод?

...