Size: a a a

2020 October 19

ML

Maksim Lapshin in ErlangRus
Vladimir Sekisov
чего-то я, наверное, недопонимаю, но вот пример, берем состояние супервизора:
16> sys:get_state(psip_tport_sup).
{state,{local,psip_tport_sup},
      one_for_one,
      {[udp1,udp2],
       #{udp1 =>
             {child,<0.673.0>,udp1,
                    {psip_tport,start_link,
                                [udp,udp1,
                                   handler =>
                                       {handler,test_handler,#{cf_mod => test_cf_simple_reg}},
                                   listen_addr => <<"10.10.0.26">>,listen_port => 5063,
                                   log_messages => false}]},
                    permanent,5000,worker,
                    [psip_tport]},
         udp2 =>
             {child,<0.672.0>,udp2,
                    {psip_tport,start_link,
                                [udp,udp2,
                                 #{handler => {handler,test_handler_test,#{}},
                                   listen_addr => <<"127.0.0.1">>,listen_port => 5069,
                                   log_messages => false}]},
                    permanent,5000,worker,
                    [psip_tport]}}},
      undefined,1,5,[],0,psip_tport_sup,[]}


ничего не мешает перебить все MFA у детей или надо еще по живым детям пройтись и им чего-то
подсунуть в состояние?
Тоже вроде бы возможно - регистрируем в каждом модуле ребенка callback типа change_state,
запрашиваем модуль у процесса через sys:get_status и проходимся по всему дереву.
ща, поясню.

Если я правильно понял, ты предлагаешь воспользоваться имеющимся OTP кодом, который позволяет апгрейдить состояние процесса, невзирая на то, какие у него должны быть новые MFA

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


Я же говорю о том, что поменяется MFA, стартовые аргументы. Процесс должен или сказать: да, я знаю как себя привести в соответствие им, или отказаться и разрешить себя рестартнуть.


Это совершенно нормальный подход, весь реакт на этом выстрелил и офигенно выстрелил, надо сказать.
источник

ML

Maksim Lapshin in ErlangRus
вот тормозить всё на время обновления конфига — очень неплохая мысль
источник

ML

Maksim Lapshin in ErlangRus
с другой стороны минутный даунтайм системы — нафиг нужно, проще рестартнуться
источник

MS

Mikhail Spiridonov in ErlangRus
Maksim Lapshin
ща, поясню.

Если я правильно понял, ты предлагаешь воспользоваться имеющимся OTP кодом, который позволяет апгрейдить состояние процесса, невзирая на то, какие у него должны быть новые MFA

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


Я же говорю о том, что поменяется MFA, стартовые аргументы. Процесс должен или сказать: да, я знаю как себя привести в соответствие им, или отказаться и разрешить себя рестартнуть.


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

VS

Vladimir Sekisov in ErlangRus
да, я, в принципе предлагаю то, что апгрейд  релиза делает, но в усеченном виде,
тк замены кода нет, так понимаю.
К сожалению в gen_* не предусмотрена трансляция system_replace_state
на пользовательский уровень, иначе бы можно было вполне элегантно и
обобщенно сделать.
источник

V

Vasilii Demidenok in ErlangRus
Макс если не поддерживаешь апдейт через релизы (а мне казалось ты релизы не используешь), то можешь спокойно писать код для миграции как предлагает Владимир
источник

V

Vasilii Demidenok in ErlangRus
или трабла в том что ты стейт собирался менять ещё? (набор полей)
источник

ML

Maksim Lapshin in ErlangRus
Vasilii Demidenok
Макс если не поддерживаешь апдейт через релизы (а мне казалось ты релизы не используешь), то можешь спокойно писать код для миграции как предлагает Владимир
я не понимаю, как можно пользоваться апдейтом кода через релизы.

Как можно мигрировать стейт?  Так что нет, не пользуюсь
источник

ML

Maksim Lapshin in ErlangRus
Vasilii Demidenok
или трабла в том что ты стейт собирался менять ещё? (набор полей)
не-не, набор полей не меняется
источник

V

Vasilii Demidenok in ErlangRus
так тогда должно работать как описано выше, или я чего-то не понимаю в твоей проблеме
источник

ML

Maksim Lapshin in ErlangRus
Vasilii Demidenok
так тогда должно работать как описано выше, или я чего-то не понимаю в твоей проблеме
надо это прожевать, но этого точно не хватит, ведь надо ещё обновить чайлдспеки внутри супервизора.
источник

jc

john conor  in ErlangRus
этих отмыть или новых наделать
источник

ИИ

Иванов Иванов... in ErlangRus
Maksim Lapshin
надо это прожевать, но этого точно не хватит, ведь надо ещё обновить чайлдспеки внутри супервизора.
так чайлдспеки и есть стейт супервизора
источник

ML

Maksim Lapshin in ErlangRus
Иванов Иванов
так чайлдспеки и есть стейт супервизора
так надо и супервизора переписывать, и детей.

Мне просто кажется немного странным обычный вызов функции замещать жестоким переписыванием стейтов =)
источник

ИИ

Иванов Иванов... in ErlangRus
Maksim Lapshin
так надо и супервизора переписывать, и детей.

Мне просто кажется немного странным обычный вызов функции замещать жестоким переписыванием стейтов =)
но ведь  удалить/добавить/обновить параметры запуска чайлда = переписать стейт супервизора
источник

ИИ

Иванов Иванов... in ErlangRus
или ты о том, что этого нет в otp и надо это хачить? ну так то да
источник

AN

Andrey Nechaev in ErlangRus
наткнулся на неприятный момент в relx.
сценарий (кривовато, но так уж есть...):
- запускаем ноду через ./blah-blah start
- периодически чекаем живость ноды через ./blah-blah ping
- через некоторое время получаем креш ноды из-за переполнения таблицы атомов.

оказывается, relx в функции relx_nodetool генерит уникальное имя , которое через
net_adm в виде атома пишется на целевую ноду
источник

AN

Andrey Nechaev in ErlangRus
причем это может вылезти не только при ./blah-blah ping, но и при remote_console и т.д.
источник

ИИ

Иванов Иванов... in ErlangRus
Andrey Nechaev
наткнулся на неприятный момент в relx.
сценарий (кривовато, но так уж есть...):
- запускаем ноду через ./blah-blah start
- периодически чекаем живость ноды через ./blah-blah ping
- через некоторое время получаем креш ноды из-за переполнения таблицы атомов.

оказывается, relx в функции relx_nodetool генерит уникальное имя , которое через
net_adm в виде атома пишется на целевую ноду
так атомы глобальны, т.е уникальны  - как может быть переполнение?
источник

ИИ

Иванов Иванов... in ErlangRus
а понял!
источник