Pull to refresh

Comments 6

Интересная статья, некоторые подходы схожи с тем, что я использовал здесь и здесь, я имею ввиду использование актуатора

https://habr.com/ru/company/otus/blog/681214/

https://habr.com/ru/company/otus/blog/682594/

Очень хотелось бы увидеть продолжение, вариант автообновления, выполненный на Spring Cloud Bus с Kafka, было бы здорово. Полагаю, что для тысяч клиентов уже было бы затруднительно без этого обойтись.

В методах refresh() сначала идет вызов init(), а потом destroy() - разве не наоборот должно быть?

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

Да, я с Вами согласен, возможно в будущем придется поддержать что-то типа@DependsOn,пока для начала, для решения текущих задач мне достаточно такой реализации, в процессе эксплуатации данного подход возможно понадобится дополнить функциональность постпроцессора. Как я упомянул в статье, сначала вообще хотелось сделать какую-то универсальную выгрузку и загрузку бина из контекста по этому событию, но немного погрузившись понял, что много чего нужно учесть и вряд ли это будет "универсально". Так что за полной универсальностью не гонюсь, будем решать проблемы по мере поступления. В любом случае, даже используя стандартные библиотеки springa все равно надо понимать как это работает, как и в случае с моим постпроцессором, чтобы понимать правильно ли работает разработанное приложение.

Про крупно-калиберную пушку не понял:)

С помощью кубера вы просто подымаете новые инстансы (с последней конфигурацией), а потом стопаете/удаляете старые инстансы. Естественно это подходит в с случае редко изменяемых конфигураций (если что-то в конфиге часто изменяется, то нужно убирать это из конфигов :-) )

Sign up to leave a comment.

Articles