[erlang-questions] Sender punishment removed

[Loïc Hoguin]

How about adding this to gen_server directly? Perhaps as a new function? 
I think this could be done with and without the expected processing time 
in a fairly generic manner.

On 01/23/2018 02:05 PM, Jesper Louis Andersen wrote:
> 
> call(Msg) ->
>      gen_server:call({Msg, erlang:monotonic_time()}).
> 
> receive
>      {Msg, In} ->
>        Out = erlang:monotonic_time(),
>        Sojourn = erlang:convert_time_unit(Out - In, native, milli_seconds),
>        case Sojourn > 5000 of
>            true -> {reply, argh, State}
>            false -> ...
>         end
> end
> 
> is usually a better way of tracking calls if you have overflow troubles. 
> Sojourn tracking and head-drop from the FIFO is what CoDel does, and it 
> works wonders on network connections. It can avoid having to process 
> messages in the queue which already fell for a timeout. Better, you can 
> do case (Sojourn + ExpectedProcessingTime) > ?LIMIT of ..., which can 
> avoid doing work which will break the time limit anyway, proactively.
> 
> 
> 
> On Tue, Jan 23, 2018 at 12:35 PM Guilherme Andrade <g@REDACTED 
> <mailto:g@REDACTED>> wrote:
> 
>     On 23 January 2018 at 10:30, Max Lapshin <max.lapshin@REDACTED
>     <mailto:max.lapshin@REDACTED>> wrote:
> 
>         1) client comes to HTTP
>         2) http handler makes gen_server:call to singleton server
>         3) waits for 5 or 60 seconds and then exits, but message is
>         already in process queue
>         4) server fetches this useless message from mailbox and starts
>         making useless expensive operations
>         5) meanwhile client makes another duplicate request and again
>         fills singleton mailbox with the same request
> 
> 
>     I've recently started to explore sbroker[1] as an alternative (in
>     some cases) and I've been getting very interesting results.
> 
>     Then again it's also (IIRC) backed by single processes that might
>     become a bottleneck themselves, but at least those processes aren't
>     doing anything else. Also, because it's this big toolkit with a lot
>     of bells and whistles, it's easy to shoot yourself in the foot if
>     you're not already acquainted with some of the abstractions, and so
>     there might be somewhat of a learning curve.
> 
>     [1]: https://github.com/fishcakez/sbroker
> 
>     -- 
>     Guilherme
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 

-- 
Loïc Hoguin
https://ninenines.eu