@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
что приведет к даунтауму в 5-10 секунд между редеплоями, но т.к бот все равно получает все новые сообщения, даже если был в ауте, то видимых проблем нет.
да. у нас на работе тоже лонг поллинг и никаких проблем. там даже время отклика быстрее.

 
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 немного снижаетс понятность кода самого сервера. а тут логика будет размазана уже между сервером и клиентом. и будет еще непонятнее.

 
у меня уже рука набита, я все шишки собрал и с vm.args и c mix внутри релиза и рестарт vs reload и кешем билда и балансировкой и обновлением кода и rpc
а ты где-нибудь выкладываешь свои наработки по деплою?

 
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, что там руководитель какой-то странный. и все. прошло.

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

 
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
 
Alex
18.09.2017
06:42:57
я чекаутю код, собираю релиз, после этого делаю рестарт релиза внутри vm. для зеро даунтаума просто кручу релиз 2-3 раза на разных портах и просто каскадно рестарт делаю
а если бд мигрейтится то запасные аппы не падают после обновления одного из них?

 
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?
а ты попробуй :)

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

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

 
Alexander
18.09.2017
06:45:47
а если бд мигрейтится то запасные аппы не падают после обновления одного из них?
скорее всего упадет все ?

 
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
 
Alexey
18.09.2017
06:53:09
пасаны, кто тут в OTP силён defmodule TestGen do use GenServer def start_link do GenServer.start_link(__MODULE__, []) end def add_message(pid, message) do GenServer.cast(pid, {:add_message, message}) end def get_messages(pid) do GenServer.call(pid, :get_messages) end # SERVER def init(messages) do {:ok, messages} end def handle_cast({:add_message, new_message}, messages) do :timer.sleep(4_000) {:noreply, [new_message | messages]} end def handle_call(:get_messages, _from, messages) do {:reply, messages, messages} end end {:ok, pid} = TestGen.start_link TestGen.get_messages(pid) [] TestGen.add_message(pid, "asd") :ok TestGen.get_messages(pid) # ВОТ ТУТ 4 СЕКУНДЫ СТОИМ ["asd"] какого хуя так работает? я думал что get_messages вообще поебать на весь мир(
вот был вопрос

 
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
в том смысле что раскидывает запросы.. ну аналогия не совсем верна )))

 
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."
кстати это прикольная штука, спасибо за инфу)

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

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

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