<div dir="ltr"><div><div><div><div>At some point writing the post, I considered<br><br></div>recieve<br></div>    Msg:Sojourn -> ...<br></div>end<br><br></div>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).<br><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 23, 2018 at 2:09 PM Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How about adding this to gen_server directly? Perhaps as a new function?<br>
I think this could be done with and without the expected processing time<br>
in a fairly generic manner.<br>
<br>
On 01/23/2018 02:05 PM, Jesper Louis Andersen wrote:<br>
><br>
> call(Msg) -><br>
>      gen_server:call({Msg, erlang:monotonic_time()}).<br>
><br>
> receive<br>
>      {Msg, In} -><br>
>        Out = erlang:monotonic_time(),<br>
>        Sojourn = erlang:convert_time_unit(Out - In, native, milli_seconds),<br>
>        case Sojourn > 5000 of<br>
>            true -> {reply, argh, State}<br>
>            false -> ...<br>
>         end<br>
> end<br>
><br>
> is usually a better way of tracking calls if you have overflow troubles.<br>
> Sojourn tracking and head-drop from the FIFO is what CoDel does, and it<br>
> works wonders on network connections. It can avoid having to process<br>
> messages in the queue which already fell for a timeout. Better, you can<br>
> do case (Sojourn + ExpectedProcessingTime) > ?LIMIT of ..., which can<br>
> avoid doing work which will break the time limit anyway, proactively.<br>
><br>
><br>
><br>
> On Tue, Jan 23, 2018 at 12:35 PM Guilherme Andrade <<a href="mailto:g@gandrade.net" target="_blank">g@gandrade.net</a><br>
> <mailto:<a href="mailto:g@gandrade.net" target="_blank">g@gandrade.net</a>>> wrote:<br>
><br>
>     On 23 January 2018 at 10:30, Max Lapshin <<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a><br>
>     <mailto:<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>>> wrote:<br>
><br>
>         1) client comes to HTTP<br>
>         2) http handler makes gen_server:call to singleton server<br>
>         3) waits for 5 or 60 seconds and then exits, but message is<br>
>         already in process queue<br>
>         4) server fetches this useless message from mailbox and starts<br>
>         making useless expensive operations<br>
>         5) meanwhile client makes another duplicate request and again<br>
>         fills singleton mailbox with the same request<br>
><br>
><br>
>     I've recently started to explore sbroker[1] as an alternative (in<br>
>     some cases) and I've been getting very interesting results.<br>
><br>
>     Then again it's also (IIRC) backed by single processes that might<br>
>     become a bottleneck themselves, but at least those processes aren't<br>
>     doing anything else. Also, because it's this big toolkit with a lot<br>
>     of bells and whistles, it's easy to shoot yourself in the foot if<br>
>     you're not already acquainted with some of the abstractions, and so<br>
>     there might be somewhat of a learning curve.<br>
><br>
>     [1]: <a href="https://github.com/fishcakez/sbroker" rel="noreferrer" target="_blank">https://github.com/fishcakez/sbroker</a><br>
><br>
>     --<br>
>     Guilherme<br>
><br>
><br>
><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
<br>
--<br>
Loïc Hoguin<br>
<a href="https://ninenines.eu" rel="noreferrer" target="_blank">https://ninenines.eu</a><br>
</blockquote></div>