[erlang-questions] Sender punishment removed

[Jesper Louis Andersen]

At some point writing the post, I considered

recieve
    Msg:Sojourn -> ...
end

but this requires an EEP, and then I realized it is better to handle this
in the language in an orthogonal fashion. But I like the point of
considering such a change on gen_server, indeed. Queue Sojourn is often a
far better metric to track on a queue rather than length (because msg
processing times differ) or bytes in the queue (because processing time
varies).


On Tue, Jan 23, 2018 at 2:09 PM Loïc Hoguin <essen@REDACTED> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180123/5ce9873c/attachment.htm>