gen_tcp:send timeout

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

gen_tcp:send timeout

dmkolesnikov
Hello,

I am looking on timeout issue with gen_tcp:send.
I’ve not discovered yet the reason but my sender process is stacked at
{current_function,{prim_inet,send,3}}

The timeout will help me but I’am confused on the way to achieve it

* gen_tcp provides an option {send_timeout, xxx}. The documentation says "The fact that the send call does not accept a timeout option, is because timeouts on send is handled through the socket option send_timeout."

* there was a recommendation for Heroku to use erlang port directly to handle timeout
send(S, Data, Timeout) ->
   true = erlang:port_command(S, Data, []),
   receive
      {inet_reply, S, Status} ->
         Status
      after Timeout ->
         {error, timeout}
   end.

What is your experience to on this issue?
What is the best way to handle it in production?

Best Regards,
Dmitry

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_tcp:send timeout

Holger Weiß
* Dmitry Kolesnikov <[hidden email]> [2014-11-12 11:16]:
> I've not discovered yet the reason but my sender process is stacked at
> {current_function,{prim_inet,send,3}}
>
> The timeout will help me but I'am confused on the way to achieve it
>
> * gen_tcp provides an option {send_timeout, xxx}. The documentation says
>   "The fact that the send call does not accept a timeout option, is
>   because timeouts on send is handled through the socket option
>   send_timeout."

I'm confused, too.  Is your process getting stuck in prim_inet:send/3
even though you specified this option?  Or is your question whether/how
to use it?

Holger
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_tcp:send timeout

dmkolesnikov
My question is about best practice. If send_timeout exists at socket option why you need to use ports directly unless there is some undocumented  issues with send_timeout

Best Regards,
Dmitry >-|-|-(*>


> On 13.11.2014, at 12.09, Holger Wei� <[hidden email]> wrote:
>
> * Dmitry Kolesnikov <[hidden email]> [2014-11-12 11:16]:
>> I've not discovered yet the reason but my sender process is stacked at
>> {current_function,{prim_inet,send,3}}
>>
>> The timeout will help me but I'am confused on the way to achieve it
>>
>> * gen_tcp provides an option {send_timeout, xxx}. The documentation says
>>  "The fact that the send call does not accept a timeout option, is
>>  because timeouts on send is handled through the socket option
>>  send_timeout."
>
> I'm confused, too.  Is your process getting stuck in prim_inet:send/3
> even though you specified this option?  Or is your question whether/how
> to use it?
>
> Holger
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_tcp:send timeout

Loïc Hoguin-3
I believe Heroku is using the port directly so the send call does not
block. The send call is synchronous, and they could not afford to wait
so they went with an asynchronous solution.

On 11/13/2014 12:21 PM, Dmitry Kolesnikov wrote:

> My question is about best practice. If send_timeout exists at socket option why you need to use ports directly unless there is some undocumented  issues with send_timeout
>
> Best Regards,
> Dmitry >-|-|-(*>
>
>
>> On 13.11.2014, at 12.09, Holger Wei� <[hidden email]> wrote:
>>
>> * Dmitry Kolesnikov <[hidden email]> [2014-11-12 11:16]:
>>> I've not discovered yet the reason but my sender process is stacked at
>>> {current_function,{prim_inet,send,3}}
>>>
>>> The timeout will help me but I'am confused on the way to achieve it
>>>
>>> * gen_tcp provides an option {send_timeout, xxx}. The documentation says
>>>   "The fact that the send call does not accept a timeout option, is
>>>   because timeouts on send is handled through the socket option
>>>   send_timeout."
>>
>> I'm confused, too.  Is your process getting stuck in prim_inet:send/3
>> even though you specified this option?  Or is your question whether/how
>> to use it?
>>
>> Holger
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
http://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_tcp:send timeout

Fred Hebert-2
We do that specifically in some critical section of logplex, but in
general, where we could, we've tried to architect things so that the
process that sends on a buffer is not the one that also needs to apply
back-pressure or load-shedding for the entire stack.

In places where we've had no choice, we indeed had to use the port
directly (with whatever the non-blocking flag was) to make sure it
wouldn't mess with the flow of data.

Regards,
Fred.

On 11/13, Loïc Hoguin wrote:

> I believe Heroku is using the port directly so the send call does not block.
> The send call is synchronous, and they could not afford to wait so they went
> with an asynchronous solution.
>
> On 11/13/2014 12:21 PM, Dmitry Kolesnikov wrote:
> >My question is about best practice. If send_timeout exists at socket option why you need to use ports directly unless there is some undocumented  issues with send_timeout
> >
> >Best Regards,
> >Dmitry >-|-|-(*>
> >
> >
> >>On 13.11.2014, at 12.09, Holger Wei� <[hidden email]> wrote:
> >>
> >>* Dmitry Kolesnikov <[hidden email]> [2014-11-12 11:16]:
> >>>I've not discovered yet the reason but my sender process is stacked at
> >>>{current_function,{prim_inet,send,3}}
> >>>
> >>>The timeout will help me but I'am confused on the way to achieve it
> >>>
> >>>* gen_tcp provides an option {send_timeout, xxx}. The documentation says
> >>>  "The fact that the send call does not accept a timeout option, is
> >>>  because timeouts on send is handled through the socket option
> >>>  send_timeout."
> >>
> >>I'm confused, too.  Is your process getting stuck in prim_inet:send/3
> >>even though you specified this option?  Or is your question whether/how
> >>to use it?
> >>
> >>Holger
> >>_______________________________________________
> >>erlang-questions mailing list
> >>[hidden email]
> >>http://erlang.org/mailman/listinfo/erlang-questions
> >_______________________________________________
> >erlang-questions mailing list
> >[hidden email]
> >http://erlang.org/mailman/listinfo/erlang-questions
> >
>
> --
> Loïc Hoguin
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions