gen_udp:send/4

[Ben Murphy]

There used to be a bug with using the inet functions and having a large message queue. Because the receive couldn’t use the selective receive optimisation it would have to scan the whole of the message queue. It looks like you have a large message queue maybe this bug still exists and effects you.

Sent from my iPhone

> On 5 Dec 2019, at 16:39, Steven <mailparmalat@REDACTED> wrote:
> 
> 
> Hi,
> 
> We have a situation where gen_udp:send/4 does not return ok and it just hangs and the process is waiting indefinitely. 
> 
> e.g.
>  {current_function,{prim_inet,sendto,4}},
>  {initial_call,{proc_lib,init_p,5}},
>  {status,running},
>  {message_queue_len,15363062},
> 
> The send buffer size on the socket is around 200KB. 
> 
> 3> inet:getopts(S, [sndbuf]).
> {ok,[{sndbuf,212992}]}
> 
> 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 enobufs or some sort but it should be quick enough to flush the sndbuf to interface.
> 
> In prim_inet:sendTo/4, it always expect inet reply from OS but it never comes and never times out.
> 
> try erlang:port_command(S, PortCommandData) of
>                         true ->
>                             receive
>                                 {inet_reply,S,Reply} ->
>                                     ?DBG_FORMAT(
>                                        "prim_inet:sendto() -> ~p~n", [Reply]),
>                                     Reply
>                             end
>                     catch
> 
> Thanks