AK
Он может вообще из erts этот логгер выкидывает и собой замещает, ентот эликсир
похоже, во всяком случае он грузится вторым и захватывает имя модуля logger себе
Size: a a a
2020 April 11
ŹR
похоже, во всяком случае он грузится вторым и захватывает имя модуля logger себе
Хотя наверное понятно почему... Чтобы там какие-нибудь райзы в кишках эликсира выглядели по эликсирски...
ŹR
Хорошего решения нету, получается...
AK
Да, какаха получается
ŹR
Походу в релизе можно нужный логгер положить, а нужный - выкинуть
ŹR
Теоретически можно написать такое в ребаре, только нафик никому не надо...
AK
Тут заморочка с очередностью, эрланговый логер грузится вместе с kernel, тоесть в начале, потом елексировский его переписывает когда стартует mix приложение, теряя при этом настройки. Как потом перегрузить ядро ерланга, чтобы вернуть логер не понятно. Не понятно так же как будет работать либа которая зачем то подтянула элексировский логер. По идее надо было кажому делать свой отдельный логер, и поддержку его настройки через rebar_mix и env из sys.config
AK
И логер получается должен поддерживать какието post_hooks чтобы можно было форснуть свои настройки после старта всех зависимостей. Короче логеры эти.. Я считаю неудачно сделаны, что в элексире что в эрланге, слишком сложно запутанно, проще надо быть..
VS
Посмотрел исходники. Не понял какую задачу решает
1. ноды можно связывать
в весьма затейливые топологии
2. протокол между нодами,
лучше,решает проблемы с большими термами
я как-то пользовался им
из-за второго пункта,
на сайте есть подробные графики
в весьма затейливые топологии
2. протокол между нодами,
лучше,решает проблемы с большими термами
я как-то пользовался им
из-за второго пункта,
на сайте есть подробные графики
TH
1. ноды можно связывать
в весьма затейливые топологии
2. протокол между нодами,
лучше,решает проблемы с большими термами
я как-то пользовался им
из-за второго пункта,
на сайте есть подробные графики
в весьма затейливые топологии
2. протокол между нодами,
лучше,решает проблемы с большими термами
я как-то пользовался им
из-за второго пункта,
на сайте есть подробные графики
Да, я потом на сайт их зашёл, почитал.
TH
Я немного другой дорогой иду. Дист в целом хорош. Его и переношу в инфру golang. Получается достойный по производительности фреймворк. До конца месяца думаю закончу с релизом и выкачу. В нем будет и хороший перформанс, и поддержка фрагментации из 22otp
VS
Тут заморочка с очередностью, эрланговый логер грузится вместе с kernel, тоесть в начале, потом елексировский его переписывает когда стартует mix приложение, теряя при этом настройки. Как потом перегрузить ядро ерланга, чтобы вернуть логер не понятно. Не понятно так же как будет работать либа которая зачем то подтянула элексировский логер. По идее надо было кажому делать свой отдельный логер, и поддержку его настройки через rebar_mix и env из sys.config
reload_logger() ->
remove_default_log_handlers(),
Level = application:get_env(kernel, logger_level, notice),
logger:set_primary_config(level, Level).
remove_default_log_handlers() ->
remove_default_log_handlers(3).
remove_default_log_handlers(N) ->
DefHlrs = logger:get_handler_ids(),
CfgHlrs = [HN || {handler, HN, _HM, _HC} <- application:get_env(kernel, logger, [])],
[ok = logger:remove_handler(HN) || HN <- DefHlrs, lists:member(HN, CfgHlrs)],
case logger:add_handlers(kernel) of
ok ->
ok;
{error, _} when N > 0 ->
timer:sleep(5),
remove_default_log_handlers(N-1);
Error={error, _} ->
Error
end.
TH
Это будет 1.1 версия. На 1.2 тоже большие планы замутить одну классную фичу с epmd
AK
reload_logger() ->
remove_default_log_handlers(),
Level = application:get_env(kernel, logger_level, notice),
logger:set_primary_config(level, Level).
remove_default_log_handlers() ->
remove_default_log_handlers(3).
remove_default_log_handlers(N) ->
DefHlrs = logger:get_handler_ids(),
CfgHlrs = [HN || {handler, HN, _HM, _HC} <- application:get_env(kernel, logger, [])],
[ok = logger:remove_handler(HN) || HN <- DefHlrs, lists:member(HN, CfgHlrs)],
case logger:add_handlers(kernel) of
ok ->
ok;
{error, _} when N > 0 ->
timer:sleep(5),
remove_default_log_handlers(N-1);
Error={error, _} ->
Error
end.
Спасибо, попробую
ML
1. ноды можно связывать
в весьма затейливые топологии
2. протокол между нодами,
лучше,решает проблемы с большими термами
я как-то пользовался им
из-за второго пункта,
на сайте есть подробные графики
в весьма затейливые топологии
2. протокол между нодами,
лучше,решает проблемы с большими термами
я как-то пользовался им
из-за второго пункта,
на сайте есть подробные графики
Че, прям стоит воткнуть вместо штатного?
VS
мне помогло, но применение было весьма ограниченное - надо было гонять большие binary и rpc
команды, а делать отдельный транспорт было лень.
На счет организации топологии нод ничего сказать
не могу, только транспорт использовал.
команды, а делать отдельный транспорт было лень.
На счет организации топологии нод ничего сказать
не могу, только транспорт использовал.
ML
мне помогло, но применение было весьма ограниченное - надо было гонять большие binary и rpc
команды, а делать отдельный транспорт было лень.
На счет организации топологии нод ничего сказать
не могу, только транспорт использовал.
команды, а делать отдельный транспорт было лень.
На счет организации топологии нод ничего сказать
не могу, только транспорт использовал.
А бинарей какой трафик?
VS
по сравнению с вашим - мелкий, но проблема была,
чтобы при передаче бинаря мегабайт на 30, rpc не залипало и не валилось
чтобы при передаче бинаря мегабайт на 30, rpc не залипало и не валилось
TH
мне помогло, но применение было весьма ограниченное - надо было гонять большие binary и rpc
команды, а делать отдельный транспорт было лень.
На счет организации топологии нод ничего сказать
не могу, только транспорт использовал.
команды, а делать отдельный транспорт было лень.
На счет организации топологии нод ничего сказать
не могу, только транспорт использовал.
Думаю, после выхода 22отп актуальность их оптимизации в транспорте больших бинарей пропала. Сейчас фрагментация в дисте есть. Так что лейтенси у мелких пакетов не должно сильно проседать
ML
по сравнению с вашим - мелкий, но проблема была,
чтобы при передаче бинаря мегабайт на 30, rpc не залипало и не валилось
чтобы при передаче бинаря мегабайт на 30, rpc не залипало и не валилось
Ага, большие бинари это зло. Мы даже тамбнейлер с диста убрали, а там жпеги по мегабайту