<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1214582572;
mso-list-type:hybrid;
mso-list-template-ids:97544380 -2039323414 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Aptos",sans-serif;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Date: 03/04/2025<o:p></o:p></p>
<p class="MsoNormal"><b><u>Participants:<o:p></o:p></u></b></p>
<p class="MsoNormal">Alexia Ingerson (Intel)<br>
Jianxin Xiong (Intel)<br>
Ben Lynam (Cornelis)<br>
Charles Shereda (Cornelis)<br>
Ian Ziemba (HPE)<br>
Jerome Soumagne (HPE)<br>
Juee Desai (Intel)<br>
Ken Raffenetti (ANL)<br>
Sai Sunku (AWS)<br>
Stephen Oost (Intel)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><u>Summary:<o:p></o:p></u></b></p>
<p class="MsoNormal">2.1.0 RC1 out, RC2 scheduled for 3/8, GA scheduled for 3/15. Mark any cherry-picks with the new “for-2.1.x” label.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">RPC issues dealing with persistent server and transient clients – new client sees stale replies intended for old client. Two PRs target this issue. #10837 updates documentation to try to decouple RDM from error cases (failure shouldn’t
close down RDM endpoint). #10792 adds a new tag format to essentially allow for ignoring unmatched messages for this case. There were mixed opinions about this solution as it seems it has a very limited (and maybe temporary) use case – don’t want to include
something too targeted in the API. Plan to look into tcp provider for provider specific implementation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><u>Notes:<o:p></o:p></u></b></p>
<p class="MsoNormal">Release 2.1.0 update:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="mso-list:l0 level1 lfo1">RC1 out 3/1/2025<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1">New branch v2.1.x<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1">RC2 scheduled for 3/8/2025<o:p></o:p></li><ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">Psm3 update<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level2 lfo1">Bug fixes for other providers<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level2 lfo1">New label “for-2.1.x”<o:p></o:p></li></ul>
<li class="MsoNormal" style="mso-list:l0 level1 lfo1">GA scheduled for 3/15/2025<o:p></o:p></li></ul>
<p class="MsoNormal">RPC issues<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="mso-list:l0 level1 lfo1">Persistent server, transient clients<o:p></o:p></li><ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">Client should not bring down server<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level2 lfo1">New client sees stale replies intended for old client<o:p></o:p></li><ul style="margin-top:0in" type="square">
<li class="MsoNormal" style="mso-list:l0 level3 lfo1">Tagged messages for replies<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level3 lfo1">Tag is specific for the reply<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level3 lfo1">State reply won’t find match (stuck in unexpected queue)<o:p></o:p></li></ul>
</ul>
<li class="MsoNormal" style="mso-list:l0 level1 lfo1">Q: there were some concerns about return EAGAIN? Is that still a concern?<o:p></o:p></li><ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">That’s more of a provider-specific detail. This PR (10837) is just to update documentation<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level2 lfo1">EAGAIN isn’t appropriate because we shouldn’t retry (client side is already down)<o:p></o:p></li></ul>
<li class="MsoNormal" style="mso-list:l0 level1 lfo1">Trying to decouple RDM endpoint from regular error cases – failure shouldn’t close down RDM endpoint<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1">Also added new error type – unreachable EP for if client died<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo1">Other PR (10792) proposes new tag format to essentially allow ignoring unmatched messages<o:p></o:p></li><ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">Reason for specifying as tag format is more to defined provider behavior<o:p></o:p></li><ul style="margin-top:0in" type="square">
<li class="MsoNormal" style="mso-list:l0 level3 lfo1">Should we focus more an application behavior?<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level3 lfo1">IZ: agree we should focus on application behavior and up to provider to handle that<o:p></o:p></li></ul>
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">IZ: What’s missing from PR is that is uses mem tag format but never explains what that means<o:p></o:p></li><ul style="margin-top:0in" type="square">
<li class="MsoNormal" style="mso-list:l0 level3 lfo1">Exact match vs TAG_BITS to use ignore bits<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level3 lfo1">Mercury uses 32 bits but don’t need to impose that for this definition. Don’t use mask, match on entire tag<o:p></o:p></li></ul>
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">Original ask was to drop unexpected messages but has turned into tag matching definitions. Are these related any more?<o:p></o:p></li><ul style="margin-top:0in" type="square">
<li class="MsoNormal" style="mso-list:l0 level3 lfo1">We don’t need it if we have a better way to handle it but not sure what that would look like<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level3 lfo1">Not really any other usage outside of this use case for tag format<o:p></o:p></li></ul>
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">In efa, use timestamp to generate unique connection id so messages for old peers can be easily identified and dropped<o:p></o:p></li><ul style="margin-top:0in" type="square">
<li class="MsoNormal" style="mso-list:l0 level3 lfo1">The issue seems to be within the provider – not being able to distinguish new connections<o:p></o:p></li></ul>
<li class="MsoNormal" style="mso-list:l0 level2 lfo1">Going to revist so we don’t introduce a new tag format for limited use case and limited time just for one provider – will look into tcp provider for provider specific implementation<o:p></o:p></li></ul>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>