Как одно приложение Plack может повлиять на другое? - PullRequest
Новая
       63

Как одно приложение Plack может повлиять на другое?

3 голосов
/ 20 мая 2011

У меня есть это: 

use Plack::Builder;
my $config_app = sub {...};
my $app = sub {...}

builder {
    mount "/admin" => $config_app;
    mount "/"   => $app;
};

$config_app сохраняет значения конфигурации в файл app.cfg и $app загружает его как файл конфигурации. Чтение конфигурационного файла в каждом запросе не требуется. Нужно прочитать его в начале приложения и перечитать его при изменении.

Как лучше всего достичь этого?

Моя единственная идея: приложение запомнит последний config_read_time и при каждом запросе будет проверять время модификации app.cfg. Если файл был изменен, перечитаем его.

Есть ли лучшее решение? (имеется в виду обмен сообщениями между $ config_app и $ app, например, когда $ config_app сохранил новую конфигурацию will send some message to $app: re-read the config.

Ответы [ 2 ]

6 голосов
/ 20 мая 2011

Несмотря на то, что невозможно набрать $app (что-то вроде внутренних перенаправлений) внутри $config_app, я лично рекомендовал бы против этого.

Должно быть намного проще, если вы создадите отдельный старый класс Perl (MyApp :: ConfigFile или любой другой) и вызовите метод как из $app, так и $config_app для одноэлементного объекта.Обратите внимание, что этот метод в любом случае работает только в среде однопроцессного веб-сервера.Если вы проверите время модификации и перечитаете, это может работать в разветвленной среде, такой как веб-сервер Starman.

5 голосов
/ 20 мая 2011

Существует множество способов мониторинга файла конфигурации.

Напишите процедуру проверки конфигурации следующим образом: 

use constant MIN_CHECK_DELAY => 5;  #SECONDS
use constant CONFIG_FILE => '/etc/wtf.conf';

{
    my $last_changed = 0;
    my $last_check   = 0;

    sub load_config {

        return if $last_check + MIN_CHECK_DELAY <= time;

        return if (stat(CONFIG_FILE))[9] <= $last_check;

        # Do stuff here.

        return;
    }

}

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

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

Это отлично подойдет для выполнения таких задач, как включение входа в запущенный процесс или принудительная перезагрузка какого-либо модуля.Существует не так много случаев, когда масштабирование не укусит вас.

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

Вот радикальное представление: почему бы не использовать базу данных?

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

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

...