<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><tt>Hi, Callum!</tt><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 18.02.2020 15:56, Callum Guy wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFjCFzn4TPDqj26cd3bQjuQq+VH2oM1_E9FKBP2+AhUB5CNzaQ@mail.gmail.com">
<div><br>
</div>
<div><font face="monospace"><a class="moz-txt-link-freetext" href="INFO:usrloc:receive_ucontact_insert">INFO:usrloc:receive_ucontact_insert</a>:
failed to fetch local urecord - creating new one (ci: '<a
href="mailto:0_751733367@10.0.0.13" moz-do-not-send="true">0_751733367@10.0.0.13</a>')
<br>
<a class="moz-txt-link-freetext" href="INFO:usrloc:receive_ucontact_update">INFO:usrloc:receive_ucontact_update</a>: failed to fetch local
urecord - create new record and contact (ci: '<a
href="mailto:0_3576574827@10.0.0.26" moz-do-not-send="true">0_3576574827@10.0.0.26</a>')<br>
<a class="moz-txt-link-freetext" href="INFO:usrloc:receive_ucontact_update">INFO:usrloc:receive_ucontact_update</a>: failed to fetch local
urecord - create new record and contact (ci: '<a
href="mailto:0_4169036315@10.0.0.12" moz-do-not-send="true">0_4169036315@10.0.0.12</a>')<br>
</font></div>
<div><br>
</div>
<div>Is this a simple matter of sessions timing out on the backup
and being removed before the next registration on the primary
instance?</div>
</blockquote>
<tt>Exactly. The UA re-REGISTERs too close to the expiration point,
creating a race</tt><tt> condition<br>
between the two nodes. By the time the backup processes the
contact</tt><tt> refresh packet, its<br>
contact is long gone, so it has nothing to match it against.
Hence this harmless INFO message.</tt><br>
<blockquote type="cite"
cite="mid:CAFjCFzn4TPDqj26cd3bQjuQq+VH2oM1_E9FKBP2+AhUB5CNzaQ@mail.gmail.com">
<div><br>
</div>
<div>Secondly I am graphing registration counts based on the
following CLI request:</div>
<div><br>
</div>
<div><font face="monospace">opensips-cli -x mi ul_dump brief=1 |
grep AOR | wc -l</font><br>
</div>
<div><br>
</div>
<div>Several times a day I see a small drop in the backup
registrations (lighter red line) before a resync operation as
shown here:</div>
<div><br>
</div>
<div><br>
</div>
<div>Can anyone help to explain what's going on here? There aren't
any log messages at this time however I do see the backup node
reporting a primary node ping loss ~1 hour before the dip:</div>
<div><br>
</div>
<div><font face="monospace">2020-02-18T11:38:37.786021+00:00
opensips[91789]: <a class="moz-txt-link-freetext" href="INFO:clusterer:do_action_trans_2">INFO:clusterer:do_action_trans_2</a>: Ping reply
not received, node [13] is down<br>
2020-02-18T11:38:38.795838+00:00 opensips[91804]:
<a class="moz-txt-link-freetext" href="INFO:clusterer:handle_internal_msg">INFO:clusterer:handle_internal_msg</a>: Node [13] is UP<br>
</font></div>
</blockquote>
<font face="monospace">This is 100% identical to what Alexey
reported in #1976 [1]. Please try to incorporate at least one of<br>
my proposed solutions -- this should make it much more harder for
the link between the nodes to do down.<br>
<br>
</font>
<p><font face="monospace">Best regards,</font></p>
<p><font face="monospace">[1]: </font><font face="monospace"><a
href="https://github.com/OpenSIPS/opensips/issues/1976">https://github.com/OpenSIPS/opensips/issues/1976</a></font></p>
<pre class="moz-signature" cols="72">--
Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com">www.opensips-solutions.com</a>
OpenSIPS Summit, Amsterdam, May 2020
<a class="moz-txt-link-abbreviated" href="http://www.opensips.org/events">www.opensips.org/events</a>
OpenSIPS Bootcamp, Miami, March 2020
<a class="moz-txt-link-abbreviated" href="http://www.opensips.org/training">www.opensips.org/training</a></pre>
</body>
</html>