SP
Если там тысячи сообщений, то проблема может быть в selective receive. Правда я не помню этот receive он в prim_inet или в gen_tcp
Size: a a a
2020 April 08
SP
Но вообще известная проблема. Не уверен что она документирована где-то
VV
А сильно выросла очередь?
33k )
VV
спасибо, очень похоже
ML
Всем привет
Erlang/OTP 17.3
стоклнулся с зависшим процессом на функции:
Счетчик редукций не увеличивался долгое время, но из-за входящих сообщений расла очередь
send_timeout установлен 30 секунд
кто может сталкивался с таким? Как решали?
Erlang/OTP 17.3
стоклнулся с зависшим процессом на функции:
prim_inet:send/3 Счетчик редукций не увеличивался долгое время, но из-за входящих сообщений расла очередь
send_timeout установлен 30 секунд
кто может сталкивался с таким? Как решали?
Интересно, зачем вообще обсуждать софт 6-летней давности?
R
Всем привет
Erlang/OTP 17.3
стоклнулся с зависшим процессом на функции:
Счетчик редукций не увеличивался долгое время, но из-за входящих сообщений расла очередь
send_timeout установлен 30 секунд
кто может сталкивался с таким? Как решали?
Erlang/OTP 17.3
стоклнулся с зависшим процессом на функции:
prim_inet:send/3 Счетчик редукций не увеличивался долгое время, но из-за входящих сообщений расла очередь
send_timeout установлен 30 секунд
кто может сталкивался с таким? Как решали?
tcpdump смотрели? может быть приемник зажал TCP window.
попробуйте использовать вариант
erlang:port_command(Socket, Data, [nosuspend]).
попробуйте использовать вариант
erlang:port_command(Socket, Data, [nosuspend]).
TH
так, вопрос...
есть супервизор, у него есть процессы - генсервера одного типа, по генсерверу на каждого подключенного клиента.
когда клиент отваливается - нужно остановить генсервер и удалить его из супервизора.
если я правильно понял для реализации нужно -
если это все происходит в cast
1) дернуть супервизора delete_child
2) в call сервера вернуть кортеж вида {stop, normal, State}
Но блин, все равно падает(
есть супервизор, у него есть процессы - генсервера одного типа, по генсерверу на каждого подключенного клиента.
когда клиент отваливается - нужно остановить генсервер и удалить его из супервизора.
если я правильно понял для реализации нужно -
если это все происходит в cast
1) дернуть супервизора delete_child
2) в call сервера вернуть кортеж вида {stop, normal, State}
Но блин, все равно падает(
Возможно стоит внимательней перечитать документацию по супервизорам и стратегиям перезапуска, чтобы подобрать подходящий. Там чтива на 5 минут, но ответ там найдется 100%. Это быстрее, эффективнее, чем здесь описывать суть своей задачи и возникшей проблемы.
c🦊
Интересно, зачем вообще обсуждать софт 6-летней давности?
Иногда обновить ERTS сложно
c🦊
хотя согласен что если это дальше эксплуатировать стоило бы постараться мигрировать на что-то поновее
c🦊
у меня R15 еще работает в одном месте и есть не просит
VV
tcpdump смотрели? может быть приемник зажал TCP window.
попробуйте использовать вариант
erlang:port_command(Socket, Data, [nosuspend]).
попробуйте использовать вариант
erlang:port_command(Socket, Data, [nosuspend]).
tcp дампа нет, но идея про nosuspend здравая, спасибо, перепроверю сейчас все флаги и добавлю
VV
Иногда обновить ERTS сложно
в процессе, но приоритетом разобраться с этим
c🦊
в процессе, но приоритетом разобраться с этим
может оказаться что после обновления ты сразу забудешь об этой проблеме
c🦊
после обновления ты о ней забудешь либо потому что все заработало, либо потому что совсем все разломалось 😂
ŹR
Ребят, кто шарит в нифках - почему может быть такая хрень?
ŹR
Ну т.е. где проеб - в эрланге или в сишечке?
c🦊
а что нифка делает?