<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:24:47 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[DRIVERS-2127] Clarify if OP_QUERY should always be used for monitoring and/or initial handshake</title>
                <link>https://jira.mongodb.org/browse/DRIVERS-2127</link>
                <project id="10980" key="DRIVERS">Drivers</project>
                    <description>&lt;p&gt;An ismaster is sent for (1) periodic SDAM monitoring and (2) during the initial handshake when opening a new socket to a server. It is not clear to me for both cases whether the ismaster should always be sent with OP_QUERY, or if we should use OP_MSG if the current server description indicates it supports OP_MSG. I think we should clarify in both cases which wire protocol to use.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/message/OP_MSG.rst#usage&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;OP_MSG spec says&lt;/a&gt;:&lt;/p&gt;
&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;OP_MSG is only available in MongoDB 3.6 (maxWireVersion &amp;gt;= 6) and later. MongoDB drivers MUST continue to perform the MongoDB Handshake using OP_QUERY to determine if the node supports OP_MSG.&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&amp;nbsp;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;If the node supports OP_MSG, any and all messages MUST use OP_MSG, optionally compressed with OP_COMPRESSED.&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;I&apos;m not sure if that means we should always use OP_QUERY for ismaster, or if we should use OP_MSG for ismaster if the current server description indicates that the server supports OP_MSG.&lt;/p&gt;

&lt;p&gt;SDAM spec says that the reply to an initial handshake ismaster should also used to &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#clients-update-the-topology-from-each-handshake&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;update the server/topology description&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;If we&apos;re using the reply to the initial handshake to update our server/topology description, then the initial handshake is a part of monitoring as well. That indicates to me that if we decide to always use OP_QUERY for monitoring, we should always do so for the handshake.&lt;/p&gt;

&lt;p&gt;FWIW, libmongoc always uses OP_QUERY for monitoring. And as was discovered in &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-3404&quot; title=&quot;Assertion hit when handshake runs against unknown server type&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-3404&quot;&gt;&lt;del&gt;CDRIVER-3404&lt;/del&gt;&lt;/a&gt;, may use OP_MSG for the handshake if the last server description had a high enough maxWireVersion.&lt;/p&gt;</description>
                <environment></environment>
        <key id="1073592">DRIVERS-2127</key>
            <summary>Clarify if OP_QUERY should always be used for monitoring and/or initial handshake</summary>
                <type id="14901" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14700&amp;avatarType=issuetype">Spec Change</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="10038" iconUrl="https://jira.mongodb.org/images/icons/subtask.gif" description="">Backlog</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="kevin.albertson@mongodb.com">Kevin Albertson</reporter>
                        <labels>
                    </labels>
                <created>Thu, 2 Jan 2020 17:55:21 +0000</created>
                <updated>Thu, 31 Mar 2022 13:49:39 +0000</updated>
                                                                <component>OP_MSG</component>
                    <component>SDAM</component>
                                        <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="2910081" author="divjot.arora" created="Wed, 26 Feb 2020 14:13:27 +0000"  >&lt;p&gt;I also agree that changing &quot;node&quot; to &quot;connection&quot; is more correct, but it is a detail that new driver implementations could easily miss. I like the idea of an &quot;implementation notes&quot; section with details like this.&lt;/p&gt;</comment>
                            <comment id="2910072" author="kevin.albertson" created="Wed, 26 Feb 2020 14:08:50 +0000"  >&lt;p&gt;I agree with Divjot&apos;s description as the intended behavior. Also relevant is to point 1 is the &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#warning-about-the-maxwireversion-from-a-monitors-ismaster-response&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Warning about the maxWireVersion from a monitor&apos;s ismaster response&lt;/a&gt; section of SDAM, which says that application socket should not use the most recent server description saved during monitoring to determine the maxWireVersion. That implies the new application sockets should use OP_QUERY for the first handshake.&lt;/p&gt;

&lt;p&gt;Changing &quot;connection&quot; to &quot;node&quot; seems reasonable. Perhaps we could take a succinct description like Divjot&apos;s comment and place that in the &quot;Implementation notes&quot; section of SDAM or in the new Server Monitoring spec? That could save future readers some investigation.&lt;/p&gt;</comment>
                            <comment id="2905357" author="shane.harvey" created="Mon, 24 Feb 2020 17:59:34 +0000"  >&lt;p&gt;What if we change this line to refer to &quot;connection&quot; instead of &quot;node&quot;:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;OP_MSG is only available in MongoDB 3.6 (maxWireVersion &amp;gt;= 6) and later. MongoDB drivers MUST continue to perform the MongoDB Handshake using OP_QUERY to determine if the connection supports OP_MSG.&lt;/p&gt;

&lt;p&gt;If a connection supports OP_MSG, all future messages using the connection MUST use OP_MSG, optionally compressed with OP_COMPRESSED.&lt;/p&gt;&lt;/blockquote&gt;</comment>
                            <comment id="2905221" author="jeff.yemin" created="Mon, 24 Feb 2020 17:29:42 +0000"  >&lt;p&gt;Note that streaming isMaster support will required OP_MSG for heartbeats, since it relies on the exhaustAllowed and moreToCome bits defined in OP_MSG.&lt;/p&gt;

&lt;p&gt;CC &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=shane.harvey&quot; class=&quot;user-hover&quot; rel=&quot;shane.harvey&quot;&gt;shane.harvey&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2699133" author="divjot.arora" created="Thu, 2 Jan 2020 18:54:38 +0000"  >&lt;p&gt;I think the use of OP_QUERY/OP_MSG for handshakes and monitoring should be split up as follows:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;When a new connection is created, OP_QUERY should be used for the initial &lt;tt&gt;isMaster&lt;/tt&gt; command, regardless of the driver&apos;s current view of the server. This is to ensure that a new connections can be established to a server that has downgraded to a pre-3.6 version. The server&apos;s &lt;tt&gt;isMaster&lt;/tt&gt; reply should be used to determine the wire version for that connection. If that wire version is &amp;gt;= 6, the connection should use OP_MSG for the rest of the handshake (e.g. auth conversation). The Go driver originally did both the &lt;tt&gt;isMaster&lt;/tt&gt; and the auth conversation using OP_QUERY, but we had a ticket from the Automation team to change this. The &lt;tt&gt;mongot&lt;/tt&gt; server does not support OP_QUERY for non-isMaster commands, so new connections could not be created with auth.&lt;/li&gt;
	&lt;li&gt;Monitoring threads should create a new connection per bullet 1. Future heartbeats should use OP_MSG if the server reported a wire version &amp;gt;= 6. This assumes that downgrading a server requires shutting it off, which would close all open connections on the server&apos;s side. In this case, if the server has downgraded in between heartbeats, the first heartbeat attempt would fail with a connection error. The monitoring thread would create a new connection per bullet 1 and the new connection would report a wire version &amp;lt; 6, so all future heartbeats would correctly use OP_QUERY.&lt;/li&gt;
&lt;/ol&gt;
</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                            <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10951" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Driver Changes</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10748"><![CDATA[Needed]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr4puf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>