Fwd: possible process_info(Pid, message_queue_len) degradation

[Rickard Green]

---------- Forwarded message ---------
From: Rickard Green <rickard@REDACTED>
Date: Thu, Apr 16, 2020 at 3:28 PM
Subject: Re: possible process_info(Pid, message_queue_len) degradation
To: Max Lapshin <max.lapshin@REDACTED>



On Wed, Apr 15, 2020 at 11:16 PM Max Lapshin <max.lapshin@REDACTED> wrote:

> Hi.
>
> We have a piece of code that does (a bad) thing:
>
>   case process_info(whereis(?MODULE), message_queue_len) of
>     {_, Len} when Len > 150 ->
>       {error, overloaded};
>
>
> On 22.1.4 it was working without any visible problems.
>
> On 22.3 we are getting problems. Process that does it is hanging in:
>
> pulsedb_appender:28 delay in writing to wal:
>
> [{erts_internal,await_result,1,[{file,"erts_internal.erl"},{line,122}]},
>  {pulsedb_wal_writer,write,1,[{file,"pulsedb_wal_writer.erl"},{line,14}]},
>
>
> Timeout of 3000 milliseconds that was not hit before, now is expired
> very often and we see that the calling process is in this new
> function.
>
>
> Question is:  could checking process_info message_queue_len become
> more expensive in 22.1.3 -> 22.3 update?
>

You probably hit this bug which was fixed in OTP 22.3.1:

  OTP-16572    Application(s): erts
               Related Id(s): ERL-1199, OTP-16269

               Fixed a bug in a receive optimization. This could cause
               a receive not to match even though a matching message
               was present in the message queue. This bug was
               introduced in ERTS version 10.6 (OTP 22.2).

Regards,
Rickard
-- 
Rickard Green, Erlang/OTP, Ericsson AB


-- 
Rickard Green, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200416/1245fb37/attachment.htm>