Сохранение уже запущенных контейнеров слушателя и откат в случае сбоя новой настройки - PullRequest
0 голосов
/ 12 июня 2019

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

При запуске, если происходит сбой, приложение не запускается, что я и хочу.Теперь о проблеме.Я создал метод reload, который позволяет пользователям изменять конфигурацию без перезапуска приложения через JMX.Итак, когда файл конфигурации изменяется, и если вызывается метод reload, выполняется следующий процесс.Действительность новой конфигурации проверяется, если она правильная, она используется для настройки новой.Для этого я сначала остановлю все контейнеры, затем уничтожу их.После этого я инициализирую новые контейнеры.Вот и все.Проблема в том, что происходит, когда возникает исключение при остановке, уничтожении или любом другом следующем шаге.Я обработал исключение, но проблема в том, что он оставит текущие настройки неработающими или недоделанными.Я хотел бы иметь функцию отката, но я не уверен, как это можно сделать.Потому что после проверки правильности новой конфигурации я установил ее как текущую.

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

Вот функция reload.RabbitManager - это класс, который я создал, он не имеет ничего особенного, просто выполняет такие действия, как stop, destroy и т. Д.

public String reloadConfiguration() {
    Rules newRules;

    // checking validity of new rules, setting it, handling exceptions...

    try {
        // setting new rules
        // rules variable saves the current rules 
        rules = newRules;

        // basically calls stop in all the containers
        rabbitManager.stopAll();
        // basically calls destroy in all the containers
        rabbitManager.destroyAllContainers();
        rabbitManager
                .init(rules) // initializes an empty map and sets rules as new rule.
                .registerListeners(); // reads rules and creates DirectMessageListenerContainer for each setting
        log.info("Configuration has been successfully changed, and stopped");
        // returns are for jConsole/monitoring
        return "Configuration has been successfully changed, and stopped";
    } catch (Exception ex) {
        log.error("Exception occurred - "+ex.getMessage(), ex);
        // returns are for jConsole/monitoring
        return "Exception : "+ex.getMessage();
    }
}

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

1 Ответ

1 голос
/ 12 июня 2019

Почему бы вам просто не stop() контейнеры и не уничтожить их только тогда, когда новые хороши. Если новая конфигурация завершится неудачно, просто start() старые контейнеры после уничтожения новых.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...