Создание сценария Perl для обнаружения изменений в отдельном модуле конфигурации также в Perl

Роб, пара моментов:

1) Предпочтительно абстрагировать средство чтения конфигурации в API, а не напрямую читать из хэша Perl. Таким образом, любой вызов этого API может, в свою очередь, решить, что нужно сделать с конфигурацией (например, включен ли таймер? Изменилась ли временная метка файла конфигурации?).

Как всегда, у этого есть дополнительное преимущество, позволяющее позже изменить конфигурацию (perl имеет => xml => база данных) без изменения какого-либо программного обеспечения.

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

Кстати, № 2 очень легко сделать, если вы следуете № 1, поскольку все, что нужно сделать обработчику «перезагрузки конфигурации», — это сбросить флаг «конфигурация должна быть перезагружена при следующем вызове API конфигурации».

3) Если вы настаиваете на том, чтобы конфигурация была хэшем без API (например, по соображениям производительности, чтобы исключить вызовы подпрограмм API, что правдоподобно, но вряд ли сильно поможет), вам нужно поместить конфигурацию в статическую переменную в вашем класс, и пусть этот класс предоставляет метод «установить новую конфигурацию». Затем сервер установит таймер, и при вызове таймера (или при получении команды «перезагрузить конфигурацию» от № 2) проверит, отличается ли отметка времени и/или контрольная сумма файла конфигурации от последнего вызова. и перезагрузить.

Если вы используете довольно новую версию Linux, всегда есть маршрут inotify. Это означает, что вы можете перезагрузить конфигурацию, как только она будет записана на диск. Ознакомьтесь с Linux-Inotify. Существует также FAM для других платформ.

Традиционный подход к такого рода проблемам на машинах типа Unix заключается в том, что серверная программа перезагружает свою конфигурацию при получении сигнал. Например, в документации Apache указано, что три сигнала имеют особое значение для сервера. : TERM сообщает серверу о завершении работы, HUP вызывает немедленный перезапуск, а USR1 запрашивает корректную перезагрузку файла конфигурации. Такую функциональность можно относительно просто встроить в вашу программу, при условии, что вы работаете в среде, которая поддерживает сигналы.

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

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

Что касается пункта 2), мы обнаружили некоторые неточности с обработкой сигналов в Perl, из-за которых он не работал с HUP, поэтому мы официально объявили устаревшие HUP-сигналы Perl для всего сайта.

Но мне очень нравится ваша идея специальной команды поиска, которая вызывает перезагрузку! Я воспользуюсь этим, если вы не возражаете. Возможно, используйте «GET 127.0.0.1», так как это, вероятно, не пройдет извне! Н.Б. Наша последняя версия нашего геопротокола основана на http, поэтому мы можем легко запросить сервис из браузера.

Спасибо! \o/