<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:36:02 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>[CSHARP-183] Driver does not handle nodes which are down gracefully</title>
                <link>https://jira.mongodb.org/browse/CSHARP-183</link>
                <project id="10041" key="CSHARP">C# Driver</project>
                    <description>&lt;p&gt;The v1.0.0.4098 version of the driver in git does not handle nodes which are down and throws a Mongo exception instead of trying other nodes which are up. &lt;br/&gt;
This also means it does not check the state of a node in while populating the seedlist. Mongo does not try other nodes when a node is down after the Mongo connection is create.&lt;/p&gt;

&lt;p&gt;Steps to reproduce:&lt;br/&gt;
1. Setup a replicaset of &amp;gt;1 nodes. &lt;br/&gt;
2. Turn off a single node&lt;br/&gt;
3. Create Mongo connection with a number of nodes in the connection string&lt;br/&gt;
4. Try and insert or query a document in any collection&lt;br/&gt;
5. MongoConnectionException is thrown&lt;/p&gt;

&lt;p&gt;I&apos;m not sure how this should be handled though, are there guidelines for drivers for handling downed nodes? It would seem bizzare if Mongo itself is resistant to node failures but the drivers aren&apos;t.&lt;/p&gt;</description>
                <environment></environment>
        <key id="15253">CSHARP-183</key>
            <summary>Driver does not handle nodes which are down gracefully</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="robert@mongodb.com">Robert Stam</assignee>
                                    <reporter username="derfel">J W Lee</reporter>
                        <labels>
                    </labels>
                <created>Thu, 24 Mar 2011 02:48:15 +0000</created>
                <updated>Thu, 2 Apr 2015 18:27:35 +0000</updated>
                            <resolved>Mon, 12 Sep 2011 21:42:17 +0000</resolved>
                                    <version>0.11</version>
                                    <fixVersion>1.2</fixVersion>
                                                        <votes>4</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="53552" author="rstam" created="Mon, 12 Sep 2011 21:42:17 +0000"  >&lt;p&gt;This has been worked on and tested with v1.2. Note that when a replica set member goes offline (or there is a change of primary) the application might still receive a small number of exceptions, but everything should return to normal after that.&lt;/p&gt;</comment>
                            <comment id="27393" author="onyxmaster" created="Thu, 31 Mar 2011 07:55:55 +0000"  >&lt;p&gt;Checked it again, &lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-187&quot; title=&quot;BsonBuffer waiting indefinitely on broken connection&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CSHARP-187&quot;&gt;&lt;del&gt;CSHARP-187&lt;/del&gt;&lt;/a&gt;, along with IOExceptions (reported them to &lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-153&quot; title=&quot;Wrapping internal communication exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CSHARP-153&quot;&gt;&lt;del&gt;CSHARP-153&lt;/del&gt;&lt;/a&gt;).&lt;/p&gt;</comment>
                            <comment id="27384" author="onyxmaster" created="Thu, 31 Mar 2011 06:56:50 +0000"  >&lt;p&gt;Last time I checked, getting server down while reading from a cursor leaded to IOException, will recheck it again.&lt;/p&gt;</comment>
                            <comment id="27352" author="derfel" created="Thu, 31 Mar 2011 00:04:14 +0000"  >&lt;p&gt;@Aristarkh Zagorodnikov&lt;/p&gt;

&lt;p&gt;There is a MongoConnectionException in the latest driver which I am using to figure out if I should wait and retry the operation or not, so &lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-153&quot; title=&quot;Wrapping internal communication exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CSHARP-153&quot;&gt;&lt;del&gt;CSHARP-153&lt;/del&gt;&lt;/a&gt; is should be considered fixed I believe.&lt;/p&gt;</comment>
                            <comment id="27332" author="onyxmaster" created="Wed, 30 Mar 2011 21:13:30 +0000"  >&lt;p&gt;While I agree with the idea that retry policy should be controlled by the client application, I think that some help from the driver would be nice. &lt;br/&gt;
I believe that in terms of retryability, operations could be broken in three broad classes:&lt;br/&gt;
1. reads &amp;#8211; apart from creating extra load on the database, little might go wrong with extra reading unless the volume is too large&lt;br/&gt;
2. &quot;absolute&quot; writes (set X to Y where Z, delete where Z) &amp;#8211; again only extra load might cause problems&lt;br/&gt;
3. &quot;relative&quot; writes (set X = X + Y where Z) &amp;#8211; here retrying operation might damage the database contents (logically)&lt;br/&gt;
While operations of kinds #1 and #2 are easily auto-retried (an interval and limit should be imposed), the kind #3 is tricky and could only either rewritten as #2 (using some kind of versioning logic built into the query), or autoretried at the client level (the client rereads current state and retries the global operation that originated the request to the database).&lt;/p&gt;

&lt;p&gt;I think that the driver might lend a hand for #1 and #2, probably in a separate namespace or even separate assembly, providing request wrappers as extension methods or utlility functions accepting delegates (anonymous methods along with extension methods aren&apos;t in .NET 2.0 IIRC, and last time I checked the driver targets the 2.0, so this might be a problem), that have reasonable defaults for interval and timeout values (i.e. 15ms default interval, timeout matching global one) that would allow writing some code like.&lt;/p&gt;

&lt;p&gt;When I used BerkeleyDB, I created a set of wrappers to retry a set operations in optional context of transaction to assist in deadlock resolution (BerkeleyDB has explicit deadlock handing, so retrying operations are done entirely on client) &amp;#8211; it helped a lot. I guess that having something similar would make writing robust .NET applications much easier, especially since mongodb clusters are so quick to recover from a failure as a whole. We did some testing in a Web environment &amp;#8211; with proper retry mechanism, users might only notice a slight response increase of time for a few seconds, instead of facing at the &quot;oompf, error 500&quot; page for the same tame.&lt;/p&gt;</comment>
                            <comment id="27331" author="onyxmaster" created="Wed, 30 Mar 2011 21:07:29 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-153&quot; title=&quot;Wrapping internal communication exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CSHARP-153&quot;&gt;&lt;del&gt;CSHARP-153&lt;/del&gt;&lt;/a&gt; is related to this, since retrying on every exception might be a bad policy, and it appears that currently, cursor operations can fail with arbitrary exceptions including IOException, SocketException, etc.&lt;/p&gt;</comment>
                            <comment id="27061" author="derfel" created="Tue, 29 Mar 2011 01:37:02 +0000"  >&lt;p&gt;That makes sense, I&apos;ll modify the code to keep retrying then. On a related note it seems that the secondaryconnectionpool property will throw an exception if empty. I&apos;m using this property to check if there are nodes that are down (compare secondaryconnectionpool servers with replicaset servers) and do a server.reconnect() to recover all the nodes in the connection pool, or is there a better way?&lt;/p&gt;

&lt;p&gt;In MongoServer.cs:&lt;/p&gt;

&lt;p&gt;  public IList&amp;lt;MongoConnectionPool&amp;gt; SecondaryConnectionPools {&lt;br/&gt;
            get &lt;/p&gt;
{ return secondaryConnectionPools.AsReadOnly(); }
&lt;p&gt;        }&lt;/p&gt;</comment>
                            <comment id="26642" author="rstam" created="Thu, 24 Mar 2011 03:00:49 +0000"  >&lt;p&gt;I will try to reproduce this, but one comment I can go ahead and make is that the driver does NOT guarantee that you won&apos;t get any exceptions. What it DOES guarantee is that if you keep retrying the operation it will eventually succeed. When the primary goes down there is a period of time while the election is taking place that there is no primary. During that period of time no operations will succeed. The first retry after a new primary has been elected will succeed.&lt;/p&gt;

&lt;p&gt;So if you are saying that even after repeated retries the operation continues to fail indefinitely, then it would be a bug. But if what you are saying is that you saw an exception that would not be a bug. That&apos;s what you should be seeing.&lt;/p&gt;

&lt;p&gt;Are you catching the exception and retrying?&lt;/p&gt;</comment>
                    </comments>
                    <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_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrh97r:</customfieldvalue>

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