<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 05 Dec 2019, at 18:39, Steven <<a href="mailto:mailparmalat@gmail.com" class="">mailparmalat@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">We have a situation where gen_udp:send/4 does not return ok and it just hangs and the process is waiting indefinitely. <br class=""></div><div class=""><br class=""></div><div class="">e.g.<br class=""></div><div class=""> {current_function,{prim_inet,sendto,4}},<br class=""> {initial_call,{proc_lib,init_p,5}},<br class=""> {status,running},<br class=""> {message_queue_len,<b class=""><font color="#e32400" class="">15363062</font></b>},</div></div></div></blockquote><div><br class=""></div>It appears that your server (e.g. process that is calling gen_udp:send/4) has way to many messages on its process queue — thus gen_udp:send/4 hanging is probably a symptom and not necessarily the cause.</div><div><br class=""><div class="">Could it be that your server itself employs a selective receive for the incoming events/requests processing, e.g.</div><div class=""><br class=""></div><div class=""><font face="Courier New" class="">main_loop()</font></div><div class=""><font face="Courier New" class="">-></font></div><div class=""><font face="Courier New" class=""> receive</font></div><div class=""><font face="Courier New" class=""> {“Some pattern”, _} -> gen_udp:send(…);</font></div><div class=""><font face="Courier New" class=""> “Some other pattern” -> do_something else(…)</font></div><div class=""><font face="Courier New" class=""> _<span class="Apple-tab-span" style="white-space:pre"> </span> -> ignore;</font></div><div class=""><font face="Courier New" class=""> after SomeTime -> do_soemthing_different() </font></div><div class=""><font face="Courier New" class=""> end,</font></div><div class=""><font face="Courier New" class=""> main_loop()</font></div><div class=""><font face="Courier New" class="">.</font></div><div class=""><br class=""></div><div class="">The construct above will slow message processing and that may account for more than 15,000,000 messages reported to be on your server's message queue.</div><div class="">In my view, selective receive is a bad idea for server-side implementation. Server should rather use something like this:</div><div class=""><br class=""></div><div class=""><font face="Courier New" class="">main_loop()</font></div><div class=""><font face="Courier New" class="">-></font></div><div class=""><font face="Courier New" class=""> receive</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Msg -> process_msg( Msg )</font></div><div class=""><font face="Courier New" class=""> after<span class="Apple-tab-span" style="white-space: pre;"> </span>SomeTime -> do_something_different()</font></div><div class=""><font face="Courier New" class=""> end,</font></div><div class=""><font face="Courier New" class=""> main_loop()</font></div><div class=""><font face="Courier New" class="">.</font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><font face="Courier New" class="">process_msg( {“Some pattern”, _} ) -> gen_udp:send(…);</font></div><div class=""><font face="Courier New" class="">process_msg( “Some other pattern” ) -> do_something_else(…);</font></div><div class=""><span style="font-family: "Courier New";" class="">process_msg( _ ) -> ignore. </span></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class="">This will always keep server’s process queue reasonably empty, thus, even when server uses a function that hides a selective receive, such function will come back reasonably quickly. </div><div class="">Kind regards</div><div class=""><br class=""></div><div class="">V/</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">The send buffer size on the socket is around 200KB. <br class=""></div><div class=""><br class=""></div><div class="">3> inet:getopts(S, [sndbuf]).<br class="">{ok,[{sndbuf,212992}]}</div><div class=""><br class=""></div><div class="">The UDP socket doesn't receive any incoming packets so it is used for sending only. Running R21-3 with redhat 7.5. Would like to ask the group under which conditions will the port not come back with inet_reply? I assume if the sndbuf is full then it should come back with
<span class="gmail-code">enobufs</span> or some sort but it should be quick enough to flush the sndbuf to interface.<br class=""></div><div class=""><br class=""></div><div class="">In prim_inet:sendTo/4, it always expect inet reply from OS but it never comes and never times out.<br class=""></div><div class=""><br class=""></div><div class="">try erlang:port_command(S, PortCommandData) of<br class=""> true -><br class=""> receive<br class=""> {inet_reply,S,Reply} -><br class=""> ?DBG_FORMAT(<br class=""> "prim_inet:sendto() -> ~p~n", [Reply]),<br class=""> Reply<br class=""> end<br class=""> catch</div><div class=""><br class=""></div><div class="">Thanks<br class=""></div></div>
</div></blockquote></div><br class=""></body></html>