Здравствуйте, SergH, Вы писали:

SH>От предложенной схемы с файлом это отличается только способом, которым лог-клиент получает сообщение. В одном случае — прямой вызов через IPC (у нас был RPC), в другом — чтение файла.
Точно уже не помню, кажется, вначале вообще делали через сокеты, потом перетащили на CORBA или SOAP — давно было.

SH>Решение с файлами лучше.
Спорно.

SH>Точнее, его можно сделать лучше, если договориться, где эти файлы лежат
Вот, здесь мы теряем гибкость. И потом лог-клиент тоже может быть удаленным, не знаю, насколько это сильное и востребованное преимущество, но нам тогда показалось это востребованным.

SH>- более четко отделены процессы, они практически не взаимодействуют.
Именно по этому критерию (а не указанному ниже) не вижу, чем как один из видов ресурсов TCP-порт хуже файла.

SH>- в случае падения/зависания лог-клиента ничего плохого не происходит. Сообщения не теряются, приложения не виснут (в напрасной попытке дождаться возврата управления из RPC)
Встроенная легкая БД решит проблему потери сообщений.
Про зависание согласен, это действительно минус, из-за которого пришлось кривоту ввести: приложение при ненахождении лог-клиента перестартовывало (или стартовало) его самостоятельно. Но ведь логика у лог-клиента донельзя тупая, мы тогда решили, что это малое зло: максимально упростили лог-клиент, чтобы уменьшить вероятность его зависания по возможному максимуму.