<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>