<div dir="ltr"><div>Thanks,</div><div><br></div><div>Seems like under CPU load and with a large volume of messages coming into the process, the selective receive will slow it down and make it look like the udp send is taking long or not acknowledged meanwhile the acknowledgement is somewhere in the message queue.<br></div><div><br></div><div><span style="font-size:11pt;font-family:"Calibri",sans-serif">Steven</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 5, 2019 at 9:32 PM Valentin Micic <<a href="mailto:v@micic.co.za">v@micic.co.za</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><blockquote type="cite"><div>On 05 Dec 2019, at 18:39, Steven <<a href="mailto:mailparmalat@gmail.com" target="_blank">mailparmalat@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>Hi,</div><div><br></div><div>We have a situation where gen_udp:send/4 does not return ok and it just hangs and the process is waiting indefinitely. <br></div><div><br></div><div>e.g.<br></div><div> {current_function,{prim_inet,sendto,4}},<br> {initial_call,{proc_lib,init_p,5}},<br> {status,running},<br> {message_queue_len,<b><font color="#e32400">15363062</font></b>},</div></div></div></blockquote><div><br></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><div>Could it be that your server itself employs a selective receive for the incoming events/requests processing, e.g.</div><div><br></div><div><font face="Courier New">main_loop()</font></div><div><font face="Courier New">-></font></div><div><font face="Courier New"> receive</font></div><div><font face="Courier New"> {“Some pattern”, _} -> gen_udp:send(…);</font></div><div><font face="Courier New"> “Some other pattern” -> do_something else(…)</font></div><div><font face="Courier New"> _<span style="white-space:pre-wrap"> </span> -> ignore;</font></div><div><font face="Courier New"> after SomeTime -> do_soemthing_different() </font></div><div><font face="Courier New"> end,</font></div><div><font face="Courier New"> main_loop()</font></div><div><font face="Courier New">.</font></div><div><br></div><div>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>In my view, selective receive is a bad idea for server-side implementation. Server should rather use something like this:</div><div><br></div><div><font face="Courier New">main_loop()</font></div><div><font face="Courier New">-></font></div><div><font face="Courier New"> receive</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>Msg -> process_msg( Msg )</font></div><div><font face="Courier New"> after<span style="white-space:pre-wrap"> </span>SomeTime -> do_something_different()</font></div><div><font face="Courier New"> end,</font></div><div><font face="Courier New"> main_loop()</font></div><div><font face="Courier New">.</font></div><div><font face="Courier New"><br></font></div><div><font face="Courier New">process_msg( {“Some pattern”, _} ) -> gen_udp:send(…);</font></div><div><font face="Courier New">process_msg( “Some other pattern” ) -> do_something_else(…);</font></div><div><span style="font-family:"Courier New"">process_msg( _ ) -> ignore. </span></div><div><font face="Courier New"><br></font></div><div>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>Kind regards</div><div><br></div><div>V/</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div>The send buffer size on the socket is around 200KB. <br></div><div><br></div><div>3> inet:getopts(S, [sndbuf]).<br>{ok,[{sndbuf,212992}]}</div><div><br></div><div>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>enobufs</span> or some sort but it should be quick enough to flush the sndbuf to interface.<br></div><div><br></div><div>In prim_inet:sendTo/4, it always expect inet reply from OS but it never comes and never times out.<br></div><div><br></div><div>try erlang:port_command(S, PortCommandData) of<br> true -><br> receive<br> {inet_reply,S,Reply} -><br> ?DBG_FORMAT(<br> "prim_inet:sendto() -> ~p~n", [Reply]),<br> Reply<br> end<br> catch</div><div><br></div><div>Thanks<br></div></div>
</div></blockquote></div><br></div></blockquote></div>