<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 05:06:11 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>[SERVER-44510] Service layer / command changes to implement exhaust isMaster</title>
                <link>https://jira.mongodb.org/browse/SERVER-44510</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;See design for details. We do not need to ensure that if the server detects a client disconnect while waiting to send a reply, the server cleans up connection resources, since that will be done in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-44523&quot; title=&quot;Cease streaming exhaust isMaster replies on error (mongod)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-44523&quot;&gt;&lt;del&gt;SERVER-44523&lt;/del&gt;&lt;/a&gt;. Leave exhaust cursors as a special case to be refactored later.&lt;/p&gt;

&lt;p&gt;Log at log level 3 whether exhaust is used.&lt;/p&gt;</description>
                <environment></environment>
        <key id="994290">SERVER-44510</key>
            <summary>Service layer / command changes to implement exhaust isMaster</summary>
                <type id="2" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14711&amp;avatarType=issuetype">New Feature</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="13201">Fixed</resolution>
                                        <assignee username="tess.avitabile@mongodb.com">Tess Avitabile</assignee>
                                    <reporter username="jesse@mongodb.com">A. Jesse Jiryu Davis</reporter>
                        <labels>
                    </labels>
                <created>Fri, 8 Nov 2019 19:43:48 +0000</created>
                <updated>Mon, 8 Jan 2024 15:22:54 +0000</updated>
                            <resolved>Mon, 16 Dec 2019 21:32:13 +0000</resolved>
                                                    <fixVersion>4.3.3</fixVersion>
                                    <component>Replication</component>
                                        <votes>0</votes>
                                    <watches>7</watches>
                                                                                                                <comments>
                            <comment id="2635115" author="xgen-internal-githook" created="Mon, 16 Dec 2019 21:15:50 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;Tess Avitabile&apos;, &apos;email&apos;: &apos;tess.avitabile@mongodb.com&apos;, &apos;username&apos;: &apos;tessavitabile&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-44510&quot; title=&quot;Service layer / command changes to implement exhaust isMaster&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-44510&quot;&gt;&lt;del&gt;SERVER-44510&lt;/del&gt;&lt;/a&gt; Implement exhaust isMaster&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/ec498c5968974012d50d6d04c26cd2cd0db87d22&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/ec498c5968974012d50d6d04c26cd2cd0db87d22&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2583857" author="tess.avitabile" created="Wed, 4 Dec 2019 19:37:29 +0000"  >&lt;p&gt;Thank you, all! I was unaware of the C++ integration tests, and I agree that this is the way to go.&lt;/p&gt;

&lt;p&gt;(Note that we do have unit test coverage of exhaust getMore in &lt;a href=&quot;https://github.com/mongodb/mongo/blob/58abcf6577982367232a6c76d1ee277a4031ed3c/src/mongo/transport/service_state_machine_test.cpp#L442&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;service_state_machine_test.cpp&lt;/a&gt;, but these tests mock out the &lt;tt&gt;ServiceEntryPoint&lt;/tt&gt;, so they only test the piece of the implementation in &lt;tt&gt;makeExhaustMessage()&lt;/tt&gt;).&lt;/p&gt;</comment>
                            <comment id="2581158" author="matthew.russotto" created="Wed, 4 Dec 2019 00:57:01 +0000"  >&lt;p&gt;I think the best way to test this is a C++ integration test.  Something like the one Lingzhi mentioned (from &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36299&quot; title=&quot;Implement support for exhaust cursors with OP_MSG in DBClientCursor&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36299&quot;&gt;&lt;del&gt;SERVER-36299&lt;/del&gt;&lt;/a&gt;) should do the job; it is using low-level commands from the DBClient so a high-level client implementation isn&apos;t necessary to test the server.  These run with a real mongod.  We never tried to test exhaust getMore with a unit test, because it doesn&apos;t really demonstrate anything.&lt;/p&gt;</comment>
                            <comment id="2581040" author="lingzhi.deng" created="Tue, 3 Dec 2019 23:04:02 +0000"  >&lt;p&gt;And we also have &lt;a href=&quot;https://github.com/mongodb/mongo/blob/3c77881955004780a8dd424434575f9dc0a5632d/src/mongo/rpc/op_msg_integration_test.cpp#L291&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/3c77881955004780a8dd424434575f9dc0a5632d/src/mongo/rpc/op_msg_integration_test.cpp#L291&lt;/a&gt; written by Will as part of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36299&quot; title=&quot;Implement support for exhaust cursors with OP_MSG in DBClientCursor&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36299&quot;&gt;&lt;del&gt;SERVER-36299&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2580994" author="jesse" created="Tue, 3 Dec 2019 22:33:25 +0000"  >&lt;p&gt;However, the other possibility is to add a C++ integration test using DBClientConnection, here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/r4.2.0/src/mongo/client/dbclient_connection_integration_test.cpp&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/r4.2.0/src/mongo/client/dbclient_connection_integration_test.cpp&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I believe this test is executed with a running mongod (or replica set or sharded cluster) available. So maybe this is an even faster route to testing exhaust ismaster. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=mira.carey%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;mira.carey@mongodb.com&quot;&gt;mira.carey@mongodb.com&lt;/a&gt; do I understand this test correctly?&lt;/p&gt;</comment>
                            <comment id="2580986" author="jesse" created="Tue, 3 Dec 2019 22:24:38 +0000"  >&lt;p&gt;I recall thinking it&apos;d take perhaps a week to add shell support for exhaust as I sketched above, for me or someone like me with a small bit of experience with the shell&apos;s C++ layer. That&apos;ll give us the kind of JSTest support for exhaust commands that we&apos;re accustomed to for other commands, so it&apos;s not merely the fastest route to testing exhaust isMaster, it might also be the &quot;best&quot;.&lt;/p&gt;</comment>
                            <comment id="2580910" author="tess.avitabile" created="Tue, 3 Dec 2019 21:47:23 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, you were correct above that we don&apos;t have a way to test exhaust isMaster currently. I had hoped we could write unit tests in service_state_machine_test.cpp, but this mocks out the &lt;tt&gt;ServiceEntryPoint&lt;/tt&gt;&#160;and only tests the functionality in &lt;tt&gt;makeExhaustMessage()&lt;/tt&gt;. Since the next invocation will be constructed in &lt;tt&gt;CmdIsMaster&lt;/tt&gt;, we would not be able to test that it is formed correctly in service_state_machine_test.cpp.&lt;/p&gt;

&lt;p&gt;I have two ideas for how we can test exhaust isMaster. The first is your suggestion above to add minimal exhaust command support in the shell.&lt;/p&gt;

&lt;p&gt;The second is to try to test exhaust isMaster in unit tests or dbtests. We could make &lt;tt&gt;DBDirectClient&lt;/tt&gt; support exhaust, but that sounds hard, since &lt;tt&gt;DBDirectClient&lt;/tt&gt; bypasses the &lt;tt&gt;ServiceStateMachine&lt;/tt&gt;. &lt;tt&gt;DBClientConnection&lt;/tt&gt; supports exhaust, but it requires us to have a running server, which we don&apos;t in the context of a unit test or dbtest.&lt;/p&gt;

&lt;p&gt;I feel a little over my head on either of these approaches. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=mira.carey%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;mira.carey@mongodb.com&quot;&gt;mira.carey@mongodb.com&lt;/a&gt;, I would appreciate your guidance.&lt;/p&gt;</comment>
                            <comment id="2579699" author="jason.carey" created="Tue, 3 Dec 2019 14:50:08 +0000"  >&lt;p&gt;From a quick scan, it&apos;s not clear to me how much extra parsing/scanning of bson we&apos;d have to do as part of the tess&apos; proposal.  If a small amount, my gut would be to deserialize/serialize, because I wouldn&apos;t expect the overhead to be large enough to produce a regression.&lt;/p&gt;

&lt;p&gt;If the serialize/deserialize proposal has another full validate in it... I might still start off with that one.  Make the change, verify that we actually have the regression, then try and fix it (rather than optimizing before we know the size of the problem).  But in that case I&apos;d expect to have to look into this again a little later down the road (given that &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-41482&quot; title=&quot;makeExhaustMessage should no longer call OpMsg::parse&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-41482&quot;&gt;&lt;del&gt;SERVER-41482&lt;/del&gt;&lt;/a&gt; did move the needle).&lt;/p&gt;</comment>
                            <comment id="2579628" author="tess.avitabile" created="Tue, 3 Dec 2019 14:23:28 +0000"  >&lt;p&gt;I agree that serializing the next response will make&#160;exhaust cursors on the oplog slower due to&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-44707&quot; title=&quot;Store commit point at which the last batch was returned in ClientCursor and use that as the lastKnownCommittedOpTime for the next synthetic getMore&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-44707&quot;&gt;&lt;del&gt;SERVER-44707&lt;/del&gt;&lt;/a&gt;. However, we shouldn&apos;t see any regression in exhaust cursors used for initial sync (and we have perf tests to alert us if this happens). We don&apos;t have any baseline for exhaust cursors on the oplog or for exhaust isMaster, so we don&apos;t need to worry about a regression.&lt;/p&gt;

&lt;p&gt;&#160;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/d86e8a5bf40f1c6edbab37bef38cd0f1d5dc062d/src/mongo/transport/service_state_machine.cpp#L117&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;This deserialization&lt;/a&gt; that &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt; pointed out would go away in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-44517&quot; title=&quot;Refactor exhaust cursors on top of exhaust isMaster code changes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-44517&quot;&gt;&lt;del&gt;SERVER-44517&lt;/del&gt;&lt;/a&gt; in my proposed solution, since we would create an exhaust message based on the existence of a next invocation, not based on the command name.&lt;/p&gt;

&lt;p&gt;Ideally, we would pass a parsed request to &lt;tt&gt;Command::run()&lt;/tt&gt;, so that we can just modify the current parsed request and not need to do any serialization/deserialization, but that would be a large change.&lt;/p&gt;</comment>
                            <comment id="2576336" author="jesse" created="Tue, 3 Dec 2019 04:30:11 +0000"  >&lt;p&gt;Interesting. Let&apos;s consider deserializing first. I think we re-parse the getMore request twice per exhaust cursor reply, once in GetMoreCmd and once here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/r4.3.2/src/mongo/transport/service_state_machine.cpp#L107&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/r4.3.2/src/mongo/transport/service_state_machine.cpp#L107&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;That might not be optimal, but I believe we can avoid making it any &lt;b&gt;worse&lt;/b&gt; if we wrap the request&apos;s BSON body in an InvocationArgs struct. &lt;/p&gt;

&lt;p&gt;Today, I think that we don&apos;t have to &lt;b&gt;serialize&lt;/b&gt; the getMore request at all, we keep reusing the first request. I hope we can preserve that behavior even when the request is wrapped in an InvocationArgs.&lt;/p&gt;</comment>
                            <comment id="2575854" author="lingzhi.deng" created="Tue, 3 Dec 2019 01:03:14 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-44707&quot; title=&quot;Store commit point at which the last batch was returned in ClientCursor and use that as the lastKnownCommittedOpTime for the next synthetic getMore&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-44707&quot;&gt;&lt;del&gt;SERVER-44707&lt;/del&gt;&lt;/a&gt; is planning to use whatever is implemented here. So depending in the design here, there could be regression in exhaust cursor performance if we want to implement something new on top of this. But I agree that the overhead of serializing/deserializing is probably small enough compared to the total time needed for running a command.&lt;/p&gt;

&lt;p&gt;And I think in general (probably not for this ticket?), it might be a good idea to minimize the appearance of BSONObj in the codebase when it isn&apos;t referring to an actual document in the database. And I think this could give us more flexibility in the long run.&lt;/p&gt;</comment>
                            <comment id="2575847" author="jesse" created="Tue, 3 Dec 2019 00:46:51 +0000"  >&lt;p&gt;I don&apos;t think we should worry much about performance. I agree with Tess that we don&apos;t expect a regression in exhaust cursor performance, and we won&apos;t see it in regular ismaster either if we ensure that ismaster only does the extra BSON serialization work if exhaust is set. Exhaust ismaster will only generate InvocationArgs occasionally so it need not be very high-performance.&lt;/p&gt;

&lt;p&gt;It sounds to me like the performance gain of Lingzhi&apos;s proposal is not worth the difficulty of implementing it. Furthermore, it might be harder to understand and maintain than the alternative, which is to serialize the next invocation as BSON. I think the alternative approach is direct and easy to understand and maintain and will perform well enough. I don&apos;t see great value in choosing a more complex solution than this.&lt;/p&gt;</comment>
                            <comment id="2575168" author="lingzhi.deng" created="Mon, 2 Dec 2019 18:42:35 +0000"  >&lt;p&gt;To reduce redundant information in my proposal, maybe we can form a &#8220;ghost&#8221; synthetic request body once (something like {isExhaust: true}) for exhaust requests and make changes to &lt;tt&gt;Command::parse&lt;/tt&gt; to &#8220;parse&#8221; from the invocation args instead of from the request body BSON. But this will require more work. Just something to consider.&lt;/p&gt;</comment>
                            <comment id="2574825" author="tess.avitabile" created="Mon, 2 Dec 2019 16:59:38 +0000"  >&lt;p&gt;We have two proposals for how a command can pass arguments to its next invocation when exhaust is enabled.&lt;/p&gt;

&lt;p&gt;I proposed that the current invocation create the BSON for the next invocation and set this in the ReplyBuilderInterface. The next invocation will receive no additional arguments.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=lingzhi.deng&quot; class=&quot;user-hover&quot; rel=&quot;lingzhi.deng&quot;&gt;lingzhi.deng&lt;/a&gt; proposed that the current invocation set command-specific arguments as an InvocationArgs in the ReplyBuilderInterface. The next invocation will use the original BSON request for its next invocation.&lt;/p&gt;

&lt;p&gt;A downside to my proposal is the cost of serializing and deserializing BSON. I don&apos;t think it would cause a performance regression in exhaust cursors, since we could use the BSON from the current invocation for the next invocation. However, for exhaust isMaster, we would need to reserialize with the latest topologyVersion. To avoid a regression in isMaster without exhaust, we would want to ensure we only do this when exhaust is set.&lt;/p&gt;

&lt;p&gt;A downside to &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=lingzhi.deng&quot; class=&quot;user-hover&quot; rel=&quot;lingzhi.deng&quot;&gt;lingzhi.deng&lt;/a&gt;&apos;s proposal is that there will be redundant information in the next invocation&apos;s BSON request and InvocationArgs. The next invocation will have to ignore the topologyVersion in the BSON request and know to use the topologyVersion in the InvocationArgs. Additionally, we will have to decide how to pass the InvocationArgs to the next invocation. We could put this in ReplyBuilderInterface, but then ReplyBuilderInterface feels like an in/out parameter.&lt;/p&gt;

&lt;p&gt;I think we should go with &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=lingzhi.deng&quot; class=&quot;user-hover&quot; rel=&quot;lingzhi.deng&quot;&gt;lingzhi.deng&lt;/a&gt;&apos;s approach for performance, but I&apos;m open to other points of view. I will also ask someone from Service Architecture to weigh in and participate when I put up a code review.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jason.chan&quot; class=&quot;user-hover&quot; rel=&quot;jason.chan&quot;&gt;jason.chan&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2565457" author="haley.connelly" created="Mon, 25 Nov 2019 21:36:34 +0000"  >&lt;p&gt;After speaking with &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, we&apos;ve decided that this ticket will be split up into two parts. &lt;/p&gt;

&lt;p&gt;(1) Introduce InvocationArgs and getNextInvocation() and setNextInvocation() methods to the ReplyBuilder interface. Additionally, overload BasicCommand::run to take a ReplyBuilderInterface. Part 1 of the code should not include tests, since we must wait for TopologyCoordinator::awaitTopologyChange to be implemented and use the future&apos;s topologyVersion for setNextInvocation().&lt;/p&gt;

&lt;p&gt;(2) Implement logic for setNextInvocation() to be called isMaster exhaust is flagged, as well as store the nextInvocation inside the DbResponse. Write tests and ensure the InvocationArgs meet the exhaust isMaster design details, using the intended topologyVersion. &lt;/p&gt;

&lt;p&gt;Since my rotation is ending soon, I will work on part 1 before this ticket is handed to someone else.&lt;/p&gt;</comment>
                            <comment id="2561703" author="tess.avitabile" created="Fri, 22 Nov 2019 14:18:43 +0000"  >&lt;p&gt;Another option is to test this in unit tests, as in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36105&quot; title=&quot;Implement server support for exhaust cursors in OP_MSG&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36105&quot;&gt;&lt;del&gt;SERVER-36105&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2560486" author="jesse" created="Thu, 21 Nov 2019 21:54:52 +0000"  >&lt;p&gt;To test this we need some client that sets exhaustAllowed in its isMaster request. Eventually drivers and the ReplicaSetMonitor will do this as part of their SDAM implementation, but not soon. Perhaps we could add minimal exhaust command support in the shell, to allow a test like this?:&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;&amp;gt; var reply = db.runCommand({isMaster: 1}, {exhaustAllowed: true})&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;&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;&amp;gt; assert(reply.moreToCome == 1)&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;   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;&amp;gt; var nextReply = db.receive() // get next reply without sending a request&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;The work would be mainly in MongoBase::Functions::runCommandWithMetadata. The MongoBase object would need a new method &quot;receive&quot;, and it&apos;d need to track whether it is currently streaming exhaust replies or not.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="994286">SERVER-44509</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="994306">SERVER-44517</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="994314">SERVER-44521</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="1009348">SERVER-44707</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="994320">SERVER-44523</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="1037084">SERVER-44954</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="1037073">SERVER-44952</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>17.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>3.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Fri, 22 Nov 2019 14:18:43 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 8 weeks, 2 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<s><a href='https://jira.mongodb.org/browse/SERVER-44509'>SERVER-44509</a></s>]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_17052" key="com.atlassian.jira.plugin.system.customfieldtypes:textarea">
                        <customfieldname>Downstream Changes Summary</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Exhaust is now supported for isMaster commands against replica set members. The command must include &amp;#39;topologyVersion&amp;#39; and &amp;#39;maxAwaitTimeMS&amp;#39;. Today the topologyVersion of the server never changes,  so isMaster responses are issued every maxAwaitTimeMS.</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_17050" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Downstream Team Attention</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="16942"><![CDATA[Needed]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>PM-1400</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>luke.bonanomi@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            4 years, 8 weeks, 2 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>jesse@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>haley.connelly@mongodb.com</customfieldvalue>
            <customfieldvalue>lingzhi.deng@mongodb.com</customfieldvalue>
            <customfieldvalue>matthew.russotto@mongodb.com</customfieldvalue>
            <customfieldvalue>mira.carey@mongodb.com</customfieldvalue>
            <customfieldvalue>tess.avitabile@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hw1bu7:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hvpmhr:</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>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="3436">Repl 2019-12-02</customfieldvalue>
    <customfieldvalue id="3437">Repl 2019-12-16</customfieldvalue>
    <customfieldvalue id="3438">Repl 2019-12-30</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_17051" key="com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes">
                        <customfieldname>Teams Impacted</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="16945"><![CDATA[Drivers]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hw0y3j:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>