@proelixir

Страница 724 из 1045
Alexander
18.09.2017
03:11:51
пока непонятно, но я все настроил, деплои и все дела. Как @Virviil проснется, сделаем CI чтобы сразу автодеплой был. Сейчас приходится выполнять руками команду, но все чекаутится, деплоится и релизится

из минусов - я забыл что телеграм не дает делать лонг поллинг больше чем в 1 поток, значит мультинода отпадает пока

что приведет к даунтауму в 5-10 секунд между редеплоями, но т.к бот все равно получает все новые сообщения, даже если был в ауте, то видимых проблем нет.

все, я обратно в отпуск )

Google
Alexander
18.09.2017
03:13:48
всем Бали в чатик

عاصم بن حارث
18.09.2017
03:14:15
?

Alexey
18.09.2017
05:34:22
Alex
18.09.2017
05:35:59
а колбеки не работают ?

Alexey
18.09.2017
05:37:32
проверяли, вроде работали.

Alexander
18.09.2017
05:40:40
да. у нас на работе тоже лонг поллинг и никаких проблем. там даже время отклика быстрее.
я тоже за LP, но 2 поллинга телеграма не работают, один вышибает другой

если для одного бота

Alex
18.09.2017
05:41:00
а почему лонг поллинг тогда используете?

Alexey
18.09.2017
05:42:06
а, это да. ошибку даёт, что уже есть. а вот слать вдвоем можно, т.к. это отдельная операция запросом через rest api, и коннект сразу закрывается.

Alexander
18.09.2017
05:42:06
а почему лонг поллинг тогда используете?
ну это не ко мне. Вообще наверное имеет смысл сделать пару нод, чтобы они общались и если какая ушла в офф, то другая начала поллить

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

Alexey
18.09.2017
05:55:57
признавайтесь честно, кому-нибудь приходилось в call отдавать noreply, запоминать ПИД и отправлять сообщение попозже, через gen_server:reply ?

Alex
18.09.2017
06:00:01
это чтобы клиент делал полинг результата?

Google
Alexey
18.09.2017
06:14:00
ну. это скорее, чтобы ГС не застревал внутри call при вызове длинных операций, чтобы другие вызовы не забили ящик сообщениями.

Alex
18.09.2017
06:18:06
аа

Alexey
18.09.2017
06:18:32
тот случай, когда ответ долгий, но нужен результат, поэтому cast не подходит

Alexander
18.09.2017
06:18:47
я вроде бы просто noreply делал и потом уже в async передавал пид куда слать

Alexey
18.09.2017
06:19:25
получается как бы синхронный вызов, но при этом весь ГС не висит. выше тут в чатике был пример на той неделе, когда после вызова каста, в котором delay 4 секунды, остальное все тормозило.

Alexander
18.09.2017
06:19:41
пиздец, вроде бы уже раз 50 настраивал деплои и все такое, и вот уже с час шаг за шагом делаю, напарываясь на все грабли что только были

Alexey
18.09.2017
06:20:28
хм. похоже деплой - это у всех боль и страдания :)

Alexander
18.09.2017
06:20:34
кстати, по первому году с эликсиром помню что время на настройку деплоя почти равно времени разработки самого аппа )

Alex
18.09.2017
06:21:00
а почему бы не запустить таску для долгой задачи и вернуть pid на нее?

а... не там же стейт

Alexander
18.09.2017
06:23:49
хм. похоже деплой - это у всех боль и страдания :)
у меня уже рука набита, я все шишки собрал и с vm.args и c mix внутри релиза и рестарт vs reload и кешем билда и балансировкой и обновлением кода и rpc

Alexey
18.09.2017
06:23:53
ну. если у тебя потребитель такого вызова готов вместо ответа call получить пид... но мне кажется, что это еще непонятнее. в том плане, что с отложенным reply немного снижаетс понятность кода самого сервера. а тут логика будет размазана уже между сервером и клиентом. и будет еще непонятнее.

Alexander
18.09.2017
06:24:57
да не особо, я же стеснительный, а вдруг то что я делаю - адовая хуета

меня тут один парень в чатике поносил, мол "что ты несешь?!" - когда я как раз про деплои рассуждал

Alexey
18.09.2017
06:25:39


Alexander
18.09.2017
06:26:10
я правда потом понял, что парень живет в своем мирке, где все охуенно

Alexey
18.09.2017
06:26:21
по ходу, деплой - он всегда такой ("адовая хуета")

дык. я тебя вот тоже сначала не понимал, когда вот ты скулил. что все плохо плохо плохо. и exrm и distillery. так это ты еще свои какие-то деплои выдумываешь. а ведь в компаниях бывают свои устоявшиеся системы деплоя, и там внезапно появляется Erlang/Elixir ..... :)

Alexander
18.09.2017
06:29:18
я к критике отношусь так - пишу что возможно я неправ, бегу еще разбираться и проверяю не обосрался ли я и потом уже на белом коне возвращаюсь и насилую оппонента

Google
Alexey
18.09.2017
06:30:12
зачем насиловать опонента?

Alexander
18.09.2017
06:31:24
для удовлетворения поруганой чести )

Alexey
18.09.2017
06:31:43
в споре выигрывает тот, кто не прав. потому что он узнает что-то новое. и если ума хватает, то может поменять свою точку зрения. а победитель, как бы, не получает ничего. остается при своем. а ты еще плюсом к этой услуге еще и насилием занимаешься ) совсем себя не бережешь. занимаешься выведением людей из тьмы, понимаш, незнания.

насильно. и бесплатно

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

вон недели 3-4 назад весь хабр бурлил по поводу X0RED, что там руководитель какой-то странный. и все. прошло.

Alex
18.09.2017
06:36:45
а как вы делаете деплой? все останавливаете копируете запускаете?

или хотдеплой?

Alexey
18.09.2017
06:37:53
я к критике отношусь так - пишу что возможно я неправ, бегу еще разбираться и проверяю не обосрался ли я и потом уже на белом коне возвращаюсь и насилую оппонента
так что ты пиши, а там уж каждый для себя решит. что-то к себе в блокнот запишет, на карандаш возьмет. а кому-то это не подойдет.

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

Dmitry
18.09.2017
06:40:11
Я всетки не понял идею с "отложенным" колом

По-моему такое не должно работать

Потому что сам по себе кол висит в receive, и если он получит noreply, то висеть больше не будет

Alexander
18.09.2017
06:41:17
а как вы делаете деплой? все останавливаете копируете запускаете?
я чекаутю код, собираю релиз, после этого делаю рестарт релиза внутри vm. для зеро даунтаума просто кручу релиз 2-3 раза на разных портах и просто каскадно рестарт делаю

Dmitry
18.09.2017
06:41:38
И когда ты потом в ящик получишь сообщение с результатом работы сервака, то в этот момент может работать любой другой ресив

И у тебе будет не восстанавливаемые состояние всего этого барахла

Я бы делал через пид и handle_info

Это очень прозрачно

Типо cast(:do_running_job)

Google
Dmitry
18.09.2017
06:43:10
И handle_info(:long_running_job_results)

Alexey
18.09.2017
06:43:48
1) пользователь запросил вычисление числа пи до 150 знака через call. это занимает минуту. он залип. его пид запомнили но в call ответили noreply и в стейт записали его запрос и пид. 2) второй пользователь запросил то же самое - тоже залип. и его запрос и пид запомнили. 3) когда параллельный с этим всем делом процесс посчитал число пи до 150го знака, то он выполняет два genserver:reply в эти два пида с результатом. 4) оба пользователя отлипнут от call почти одновременно, получив одинаковый результат вычисления

это вот тоже очень прозрачно

Alex
18.09.2017
06:45:02
а клиент не отвалится ког сервер скажет noreply?

Alexey
18.09.2017
06:45:06
с точки зрения клиента. колл и все. ждем.

клиент отвалится, если ты не ответил noreply или reply через default 5секунд

Dmitry
18.09.2017
06:45:42
а клиент не отвалится ког сервер скажет noreply?
Я вот тоже думал, что noreply пошлёт ответ назад в receive

Alex
18.09.2017
06:45:49
а я пробовал были ошибки я забил

Alexander
18.09.2017
06:45:54
но это мелкая проблема

Alex
18.09.2017
06:45:58
потому что просто пробовал

Alexey
18.09.2017
06:47:47
да не. оно работает. только от этого код гс становится менее понятен. потому что окончание вычислений находится где-то за пределами тела call и его надо дополнительно искать.

Alex
18.09.2017
06:48:55
но это мелкая проблема
кто-то)) писал что мол не заморачивайтесь вы с этим хот деплоем, больше гемороя и все такое. просто стопаете апп запускаете и все ... вроде же не долгий процесс (если это конечно не какая то банковская хрень)

Alexander
18.09.2017
06:49:33
зависит от размера аппа и мощности машины

если апп с кучей под аппов, то даунтайм под 30 секунд

хоткодрелоад боль и отчаяние если это в континиус режиме

если деплоить раз в 10 лет на продакшн типа биржи, то да - это круто

Alexey
18.09.2017
06:51:28
http://erlang.org/doc/man/gen_server.html#reply-2 http://erlang.org/doc/man/gen_server.html#Module:handle_call-3 "...If {noreply,NewState} is returned, {noreply,NewState,Timeout}, or {noreply,NewState,hibernate}, the gen_server process continues executing with NewState. Any reply to From must be specified explicitly using reply/2."

Google
Alex
18.09.2017
06:56:15
http://erlang.org/doc/man/gen_server.html#reply-2 http://erlang.org/doc/man/gen_server.html#Module:handle_call-3 "...If {noreply,NewState} is returned, {noreply,NewState,Timeout}, or {noreply,NewState,hibernate}, the gen_server process continues executing with NewState. Any reply to From must be specified explicitly using reply/2."
так это специально сделали такую хрень чтобы сервер с одной стороны выполнян синхронные запросы а с другой стороны всегда готов был принять новый запрос... это типа роутера..

Andrey
18.09.2017
06:56:26
Я не очень понял в чем вопрос, но я так делал.

Alexey
18.09.2017
06:56:55
Я не очень понял в чем вопрос, но я так делал.
вот это я и хотел услышать. что кто-то так в принципе делал

Alex
18.09.2017
06:56:57
работает по принципу socket.listen

Andrey
18.09.2017
06:57:39
И в call можно передавать таймаут и падать не через 5 секунд а через 20, например

Nikolay
18.09.2017
06:57:52
еще бы кто-нибуль гист запилил с рабочим примером)

Alex
18.09.2017
06:59:22
ну или какой нить балансировшик запросов можно сделать, где сревер будет хранить в стейте загруженность рабочих процесов

Alexander
18.09.2017
07:01:41
а большая?
большая, когда все упало и не может подняться

некий процент 500х это ок

т.е балнсер в момент помечает их как нездоровые и не пойдет туда некоторое время

это не так, что все в жопу упало, просто часть нод все еще сервят старый код и могут улетать в 500

другое дело если релиз просто рерайт всего, тогда будет колапс, но девелоперы обычно не идиоты и не делают мегамиграций чтобы вот все в жопу упало

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

если все в режиме CI/CD то таких проблем обычно нет, да и проблемы деплоя быстро вскроются на стейджинге

Alex
18.09.2017
07:05:33
это да, с миграцией БД, мне кажетс везде непросто

работает по принципу socket.listen
в том смысле что раскидывает запросы.. ну аналогия не совсем верна )))

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

Alexander
18.09.2017
07:15:58
докер тут вообще не нужен )

Страница 724 из 1045