<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 7/23/20 1:52 PM, Fred Hebert wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFA3VZJbpE1bTg-uS7hrwcFSO05HPk-vd2053fxedLSR=bhyYw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div>The release notes for ERTS-10.7.1 mention:</div>
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Fixed a bug in a receive
optimization. This could cause a <span>receive</span> 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).<br>
Own Id: OTP-16572 Aux Id: ERL-1199, OTP-16269 </blockquote>
</div>
<div><br>
</div>
<div>We were on ERTS-10.6.2 (OTP-22.1.??). Today we reproduced
it again and I knew just what to look for so:</div>
<div>
<pre style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">(rabbit@rabbitmq-1-0)16> lists:filter(fun({_Pid, _Ref, {sync_notify, _}}) -> false; (_) -> true end,
(rabbit@rabbitmq-1-0)16> element(2,recon:info(rabbit_log_connection_lager_event, messages))).
[{#Ref<0.229770800.3298820110.79067>,ok}]</pre>
</div>
<div>And where we have it. Out of 85,000 messages or so in that
worker, only one of them wasn't a blocked <span
style="font-family:monospace">sync_notify</span>, and it was
a message of the form <span style="font-family:monospace">{Ref,
ok}</span> which entirely matches the compiler bug. I can't
say for sure it's the right response, but assuming things are
synchronous there's no reason we'd have another one either.
We're upgrading to Erlang/OTP-22.3.1 or newer (which contains
ERTS-10.7.1). I'm very surprised that the compiler bug had an
effect on <span style="font-family:monospace">gen:call()</span>
rather than just the branching pattern in <span
style="font-family:monospace">socket<span
style="font-family:arial,sans-serif"> (but somewhat
relieved because it would otherwise imply another bug)</span></span>.
Out of caution, we'll have engineers try to reproduce it once
more to see if that fixes it.<br>
</div>
</div>
</blockquote>
The erts-10.6.2 release was included in Erlang/OTP 22.2.2 [1], so it
must be that release or a custom release based on it. The
erts-10.7.1 release with Erlang/OTP 22.3.1 [2] does have an
important fix (OTP-16572 is the Ericsson identifier and ERL-1199 is
the bugs.erlang.org identifier) since that should impact all the OTP
behaviors that create synchronous messages (due to taking advantage
of the {Ref, _} optimization). Good to know, to make sure
development is using a version >= 22.3.1.<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://erlang.org/pipermail/erlang-questions/2020-January/098996.html">https://erlang.org/pipermail/erlang-questions/2020-January/098996.html</a><br>
[2]
<a class="moz-txt-link-freetext" href="http://erlang.org/pipermail/erlang-questions/2020-April/099386.html">http://erlang.org/pipermail/erlang-questions/2020-April/099386.html</a><br>
</body>
</html>