<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 03:21:26 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-9788] mongos does not re-evaluate read preference once a valid replica set member is chosen</title>
                <link>https://jira.mongodb.org/browse/SERVER-9788</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;div class=&quot;panel&quot; style=&quot;background-color: #EEEEEE;border-color: #ccc;border-width: 1px;&quot;&gt;&lt;div class=&quot;panelHeader&quot; style=&quot;border-bottom-width: 1px;border-bottom-color: #ccc;background-color: #6CB33F;&quot;&gt;&lt;b&gt;Issue Status as of Jul 22, 2014&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;panelContent&quot; style=&quot;background-color: #EEEEEE;&quot;&gt;
&lt;p&gt;&lt;b&gt;ISSUE SUMMARY&lt;/b&gt;&lt;br/&gt;
When reading from a sharded cluster via mongos with a specific read preference, mongos never re-evaluates the preference as long as it connects to a valid member. This can in certain circumstances lead to situations where mongos reads from nodes for prolonged times that do not match the user&apos;s intention and expectation.&lt;/p&gt;

&lt;p&gt;Example: &lt;/p&gt;

&lt;p&gt;When the &quot;secondaryPreferred&quot; read preference is set, mongos connects to an available secondary on a new connection for reads. If there are no longer any available secondaries, mongos correctly switches to a primary node. However, even when a secondary node is available again, mongos does not switch back to read from the secondary node. The connection is pinned to the primary because under &quot;secondaryPreferred&quot;, the primary is a valid target to read from and no re-evaluation is carried out until the the target becomes invalid or unreachable.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;USER IMPACT&lt;/b&gt;&lt;br/&gt;
Reads can go to primary nodes for prolonged times even though the user specified that they prefer secondary reads. Users may not even be aware of this fact, if they don&apos;t closely monitor the state of their replica sets at all times. Depending on the application architecture, this can lead to degraded read and write throughput.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;WORKAROUNDS&lt;/b&gt;&lt;br/&gt;
The only workaround is to forcibly unpin the connection by specifying a different readPreference on said connection. &lt;/p&gt;

&lt;p&gt;&lt;b&gt;AFFECTED VERSIONS&lt;/b&gt;&lt;br/&gt;
All previous production releases are affected by this issue.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;FIX VERSION&lt;/b&gt;&lt;br/&gt;
The fix is included in the 2.6.4 production release.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;RESOLUTION DETAILS&lt;/b&gt;&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Secondary connections are now drawn from the global pool.&lt;/li&gt;
	&lt;li&gt;For mongos, the active ReplicaSet connection will release its secondary connection back to the pool after the end of the query/command. This also has a side effect of &apos;unpinning&apos; the read preference settings. In other words, when this connection is reused again, the node selection will be evaluated again according to the read preference.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;As these changes could not be backported to 2.6, a different fix was implemented specifically for 2.6: a new mongos server parameter, &lt;tt&gt;internalDBClientRSReselectNodePercentage&lt;/tt&gt; was introduced. This can be set to any value from 0 to 100 (defaults to 0) and represents the probability (expressed in percentage) of a replica set connection in mongos to reevaluate replica set node selection from scratch, regardless of the compatibility of the current read preference to the last-used secondary node. Extra care should be taken since reselecting a replica set node will destroy the old connection and create a new connection.  This means in extreme cases (for example, 100%), mongos can be creating and destroying connections for every read request.&lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h6&gt;&lt;a name=&quot;Originaldescription&quot;&gt;&lt;/a&gt;Original description&lt;/h6&gt;

&lt;p&gt;During lab tests with 1 primary, 1 secondary and 1 arbiter I&apos;m running into the following issue when using the Java drivers&apos; &quot;secondaryPreferred&quot; read preference :&lt;/p&gt;

&lt;p&gt;We start with a healthy 3 member repset and start our load tests. This load test connects to mongos. All reads go to the secondary member. We kill the secondary and reads are correctly routed to the primary. We restart the secondary but reads continue to go to the primary indefinitely.&lt;/p&gt;

&lt;p&gt;Might be a Java driver issue since I was not able to reproduce in shell due to the lack of support for this read mode there (I think?)&lt;/p&gt;</description>
                <environment>All</environment>
        <key id="76746">SERVER-9788</key>
            <summary>mongos does not re-evaluate read preference once a valid replica set member is chosen</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</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="9">Done</resolution>
                                        <assignee username="randolph@mongodb.com">Randolph Tan</assignee>
                                    <reporter username="remonvv">Remon van Vliet</reporter>
                        <labels>
                    </labels>
                <created>Tue, 28 May 2013 09:00:22 +0000</created>
                <updated>Wed, 8 Feb 2023 14:44:51 +0000</updated>
                            <resolved>Mon, 30 Jun 2014 17:23:09 +0000</resolved>
                                    <version>2.4.3</version>
                                    <fixVersion>2.6.4</fixVersion>
                    <fixVersion>2.7.3</fixVersion>
                                    <component>Sharding</component>
                                        <votes>4</votes>
                                    <watches>20</watches>
                                                                                                                <comments>
                            <comment id="761215" author="michael.paik" created="Tue, 11 Nov 2014 15:40:31 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=renctan&quot; class=&quot;user-hover&quot; rel=&quot;renctan&quot;&gt;renctan&lt;/a&gt;, is removing this bullet point the &lt;b&gt;only&lt;/b&gt; applicable change?&lt;/p&gt;</comment>
                            <comment id="667606" author="renctan" created="Tue, 22 Jul 2014 15:36:50 +0000"  >&lt;p&gt;More conservative fix for v2.6:&lt;/p&gt;

&lt;p&gt;Added a new mongos server parameter, &quot;internalDBClientRSReselectNodePercentage&quot;. This can be set to any value from 0 to 100 (defaults to 0) and represents the probability (expressed in percentage) of a replica set connection in mongos to reevaluate replica set node selection from scratch, regardless of the compatibility of the current read preference to the currently pinned node. Extra care should be taken since v2.6 doesn&apos;t pool secondary connections, so unpinning a node from the replica set connection has a side effect of destroying the connection. This means in extreme cases (for example, 100%), mongos can be creating and destroying connections for every read request.&lt;/p&gt;</comment>
                            <comment id="667603" author="xgen-internal-githook" created="Tue, 22 Jul 2014 15:34:55 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;renctan&apos;, u&apos;name&apos;: u&apos;Randolph Tan&apos;, u&apos;email&apos;: u&apos;randolph@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-9788&quot; title=&quot;mongos does not re-evaluate read preference once a valid replica set member is chosen&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-9788&quot;&gt;&lt;del&gt;SERVER-9788&lt;/del&gt;&lt;/a&gt; mongos does not respect secondary preferred after temporarily unavailable secondary&lt;/p&gt;

&lt;p&gt;v2.6 fix: Added server parameter to tweak the frequency of when a replica set connection will decide when it needs to re-evaluate the node selection from scratch for a query with read prefrerence (i.e., decide not to use the cached connection regardless of read prefrerece compatibility).&lt;br/&gt;
Branch: v2.6&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/10f5eb6b0d3eee62fbd7492a2ab4745306e0f54e&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/10f5eb6b0d3eee62fbd7492a2ab4745306e0f54e&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="657845" author="remonvv" created="Mon, 14 Jul 2014 10:33:42 +0000"  >&lt;p&gt;Great, that sounds like the appropriate fix.&lt;/p&gt;</comment>
                            <comment id="639004" author="renctan" created="Mon, 30 Jun 2014 18:09:52 +0000"  >&lt;p&gt;Changes made:&lt;/p&gt;

&lt;p&gt;1. Secondary connections are now drawn from the global pool.&lt;br/&gt;
2. For mongos, the active replset connection will release the secondary connections back to the pool. To be more precise, the thread local ClientConnection object will do this. This also has a side effect of &apos;unpinning&apos; the read preference settings. In other words, when this connection is reused again, the node selection for read preference will be evaluated again from scratch.&lt;/p&gt;</comment>
                            <comment id="638923" author="xgen-internal-githook" created="Mon, 30 Jun 2014 17:22:05 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;renctan&apos;, u&apos;name&apos;: u&apos;Randolph Tan&apos;, u&apos;email&apos;: u&apos;randolph@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-9788&quot; title=&quot;mongos does not re-evaluate read preference once a valid replica set member is chosen&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-9788&quot;&gt;&lt;del&gt;SERVER-9788&lt;/del&gt;&lt;/a&gt; mongos does not respect secondary preferred after temporarily unavailable secondary&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/09d2bf2a43cbf6e7ac10d4dc89934528001d0b69&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/09d2bf2a43cbf6e7ac10d4dc89934528001d0b69&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="489727" author="scotthernandez" created="Tue, 28 Jan 2014 22:33:17 +0000"  >&lt;p&gt;The java driver exhibits this behavior because it has a long-lived connection pool, and once the pooled connections map to a backend, it sticks to that one, providing consistency (see below).&lt;/p&gt;

&lt;p&gt;The goal is not to distribute each individual request/operation to load balance across the available replicas but more to handle distribution of those connection when the sockets/connects are established. This will yield the most consisten view of the data because it will not result in reads from different replicas across the window of replication (so you don&apos;t see new data, then old data) thus leading to reads in order other than normal time.&lt;/p&gt;

&lt;p&gt;Remon, replicas are not really good for good for read-scaling, unfortunately; if you want to scale, read or write, it is best to add more shards, not replicas. There are some exceptions from this, but they are few are far between and related to over-saturating nodes and/or large node latencies.&lt;/p&gt;

&lt;p&gt;If you have a specific use-case it would be good to provide it here so we can suggest what to do.&lt;/p&gt;</comment>
                            <comment id="455176" author="cccnyc1ixk" created="Tue, 12 Nov 2013 21:02:58 +0000"  >&lt;p&gt;We are experiencing the same issue. In our tests it seems to be pointing to java driver not able to utilize restarted available secondary server. &lt;/p&gt;</comment>
                            <comment id="447455" author="vinod.k" created="Mon, 28 Oct 2013 07:10:49 +0000"  >&lt;p&gt;Hi any updates on this .  Seems like we saw the same behaviour in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-11117&quot; title=&quot;Tagged Secondary Preffered not working as expected - Reads always happening at Primary &quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-11117&quot;&gt;&lt;del&gt;SERVER-11117&lt;/del&gt;&lt;/a&gt; . &lt;br/&gt;
Am also curious to know what is the setting specific to the  Java driver that you have explained above&lt;/p&gt;</comment>
                            <comment id="363257" author="remonvv" created="Wed, 19 Jun 2013 11:43:00 +0000"  >&lt;p&gt;Any updates on this? I would like to know what the decisions, if any, are regarding this issue since it might mean we&apos;ll have to start working on a workaround.&lt;/p&gt;</comment>
                            <comment id="353470" author="remonvv" created="Wed, 5 Jun 2013 11:06:45 +0000"  >&lt;p&gt;1) Ah, yes that pretty much explains it. Probably good to provide a link to that section in the read preferences docs &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;br/&gt;
2) I was not aware of this. Any particular reason the Java driver is an exception to the common implementation that you&apos;re aware of?&lt;br/&gt;
3) Okay, I would really appreciate a decision one way or the other since it affects whether or not we can reliably use secondaries for read scaling.&lt;/p&gt;</comment>
                            <comment id="349824" author="renctan" created="Fri, 31 May 2013 13:56:46 +0000"  >&lt;p&gt;1) Although it was not clear in the documentation, the pinning behavior was described in the &lt;a href=&quot;http://docs.mongodb.org/manual/core/read-preference/#auto-retry&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;auto-retry section&lt;/a&gt;.&lt;br/&gt;
2) Actually, the Java driver is a special case where the pinning behavior must be explicitly requested by the user.&lt;br/&gt;
3) You have a point. We will discuss this internally and look for ways to solve this issue.&lt;/p&gt;</comment>
                            <comment id="348712" author="remonvv" created="Thu, 30 May 2013 10:50:02 +0000"  >&lt;p&gt;I understand but it&apos;s rather time consuming to isolate the test as it&apos;s currently built on top of some in-house tooling. It&apos;s almost certainly the pinning behaviour. I have a test that runs 20 threads that all do random reads from a test collections at maximum throughput. Database configuration is as described.&lt;/p&gt;

&lt;p&gt;I would argue this is actually a bug rather than a feature request for the following reasons :&lt;/p&gt;

&lt;p&gt;1) The contract for secondaryPreferred as described in the documentation is &quot;... read from secondary members, but in situations where the set consists of a single primary (and no other members,) the read operation will use the set&#8217;s primary.&quot;. Currently it does not adhere to this (it will read from a primary in situations where there ARE other members).&lt;/p&gt;

&lt;p&gt;2) The behaviour between connecting to a repset directly compared to through mongos is currently not consistent. Drivers behave correctly (as in, do as advertised) whereas mongos does not.&lt;/p&gt;

&lt;p&gt;3) The current behaviour can lead to prolonged significantly degraded read and write throughput while a by then perfectly healthy secondary was available. With sufficiently long cluster uptimes this would almost certainly lead to situations where secondary nodes cannot be counted on to carry read load.&lt;/p&gt;

&lt;p&gt;Hope you agree.&lt;/p&gt;
</comment>
                            <comment id="348075" author="renctan" created="Wed, 29 May 2013 17:19:11 +0000"  >&lt;p&gt;I just wanted to make sure that the one you are experiencing is just the pinning behavior or something else. If this is indeed the pinning behavior then I will convert this into a feature request to allow unpinning of connections.&lt;/p&gt;</comment>
                            <comment id="347943" author="remonvv" created="Wed, 29 May 2013 14:48:01 +0000"  >&lt;p&gt;I understand the reasoning and it&apos;s perfectly valid for various usecases but I think that&apos;s a developer decision to make. If they want to avoid that behaviour they should not have a read preference &quot;secondary preferred&quot; which implies the expectation that it will switch from primary to secondary when the latter becomes available. In that case the developer clearly prioritizes removing read load from the primary. I also don&apos;t think the back in time issue is that relevant for scenarios where developers have to take eventual consistency into account anyway (it is not different from switching from one secondary to the next if they are at different position in the oplog).&lt;/p&gt;

&lt;p&gt;I don&apos;t have a very practical way to share the entire test unfortunately. Are you not able to reproduce? &lt;/p&gt;</comment>
                            <comment id="347926" author="renctan" created="Wed, 29 May 2013 14:35:04 +0000"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;Can you share the test project?&lt;/p&gt;

&lt;p&gt;The reasoning behind the pinning logic was to avoid going back in time as much as possible. For example, if doc A was deleted at time T and client is connected to node0 which has optime &amp;gt; T, we want to avoid the situation where client switches to node1 which has optime &amp;lt; T and make doc A visible to it. So the jump from the view of the world at optime &amp;gt; T to optime &amp;lt; T was what I was referring to as &quot;going back in time&quot;.&lt;/p&gt;</comment>
                            <comment id="347730" author="remonvv" created="Wed, 29 May 2013 09:41:26 +0000"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;Yes that is the behaviour I&apos;m seeing. I would argue that that is not correct behaviour. Secondary preferred read preference should do exactly that and prefer secondary nodes when they are available. It is currently not following that contract and there are very valid reasons why you would not want the current behaviour. Additionally the behaviour isn&apos;t consistent with accessing repsets directly rather than through mongos. My test is multi-threaded by the way.&lt;/p&gt;</comment>
                            <comment id="347045" author="renctan" created="Tue, 28 May 2013 17:25:32 +0000"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;The mongos pins the node chosen unless the node becomes unreachable or the read preference setting becomes incompatible with the selected node. In addition, mongos also uses pooled connection so if your test is single threaded, it is very likely that it is using the same connection from the pool that was pinned.&lt;/p&gt;</comment>
                            <comment id="346856" author="remonvv" created="Tue, 28 May 2013 14:21:35 +0000"  >&lt;p&gt;Note that it works perfectly fine if the driver connects directly to the repset rather than through mongos.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                                        </outwardlinks>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10320">
                    <name>Documented</name>
                                                                <inwardlinks description="is documented by">
                                        <issuelink>
            <issuekey id="173224">DOCS-4484</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="150765">SERVER-14781</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="91521">SERVER-10904</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56054">SERVER-7629</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="79891">SERVER-9984</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="231419">DOCS-6268</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="145710">CXX-275</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="84954">SERVER-10449</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="28547">SERVER-4706</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="152634">SERVER-14899</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10220">
                    <name>Tested</name>
                                            <outwardlinks description="tested by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>19.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_12451" key="com.atlassian.jira.plugin.system.customfieldtypes:multiversion">
                        <customfieldname>Backport Completed</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="14092">2.6.4</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 28 May 2013 17:25:32 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        9 years, 14 weeks, 1 day 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/WRITING-892'>WRITING-892</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_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>
                            9 years, 14 weeks, 1 day ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>cccnyc1ixk</customfieldvalue>
            <customfieldvalue>michael.paik</customfieldvalue>
            <customfieldvalue>randolph@mongodb.com</customfieldvalue>
            <customfieldvalue>remonvv</customfieldvalue>
            <customfieldvalue>scotthernandez</customfieldvalue>
            <customfieldvalue>vinod.k</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrmruf:</customfieldvalue>

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

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>7147</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_10750" key="com.atlassian.jira.plugin.system.customfieldtypes:textarea">
                        <customfieldname>Steps To Reproduce</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>&lt;p&gt;1) Create and start 3 member repset (primary, secondary, arbiter)&lt;br/&gt;
2) Start mongos&lt;br/&gt;
3) Send reads to mongos, verify they go to SEC&lt;br/&gt;
4) Kill SEC&lt;br/&gt;
5) Send reads to mongos, verify they go to PRI&lt;br/&gt;
6) Restart SEC&lt;br/&gt;
7) Send reads to mongos, verify they go to SEC (they don&apos;t).&lt;/p&gt;</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_11861" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>User Summary</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="11858"><![CDATA[Completed]]></customfieldvalue>

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

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