<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:21: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>[DRIVERS-222] Deprecate connectTimeoutMS?</title>
                <link>https://jira.mongodb.org/browse/DRIVERS-222</link>
                <project id="10980" key="DRIVERS">Drivers</project>
                    <description>&lt;p&gt;A number of drivers support the connectTimeoutMS URI option. The introduction of serverSelectionTimeoutMS seems to make this far less of a useful user facing option. We still need a select timeout for making an initial socket.connect() call, but from a driver behavior perspective serverSelectionTimeoutMS will always appear to dominate (at least for multi-threaded languages). Should we deprecate connectTimeoutMS?&lt;/p&gt;

&lt;p&gt;See &lt;a href=&quot;https://jira.mongodb.org/browse/PYTHON-908&quot; title=&quot;Document serverSelectionTimeoutMS. Clarify connectTimeoutMS / socketTimeoutMS.&quot; class=&quot;issue-link&quot; data-issue-key=&quot;PYTHON-908&quot;&gt;&lt;del&gt;PYTHON-908&lt;/del&gt;&lt;/a&gt; for a related discussion.&lt;/p&gt;</description>
                <environment></environment>
        <key id="199266">DRIVERS-222</key>
            <summary>Deprecate connectTimeoutMS?</summary>
                <type id="4" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14710&amp;avatarType=issuetype">Improvement</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="2">Won&apos;t Fix</resolution>
                                        <assignee username="david.golden@mongodb.com">David Golden</assignee>
                                    <reporter username="bernie@mongodb.com">Bernie Hackett</reporter>
                        <labels>
                    </labels>
                <created>Tue, 21 Apr 2015 15:15:25 +0000</created>
                <updated>Tue, 17 Mar 2020 02:28:19 +0000</updated>
                            <resolved>Tue, 4 Oct 2016 20:20:12 +0000</resolved>
                                                                            <votes>0</votes>
                                    <watches>5</watches>
                                                                                                                <comments>
                            <comment id="1400107" author="rathi.gnanasekaran" created="Tue, 4 Oct 2016 20:21:39 +0000"  >&lt;p&gt;Closing the ticket because we decided not to deprecate connectTimeoutMS option. &lt;/p&gt;</comment>
                            <comment id="894086" author="jesse" created="Tue, 21 Apr 2015 17:54:12 +0000"  >&lt;p&gt;That&apos;s great David.&lt;/p&gt;</comment>
                            <comment id="894030" author="david.golden" created="Tue, 21 Apr 2015 17:09:05 +0000"  >&lt;p&gt;How about:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;connectTimeoutMS &#8211; this option controls how long the driver will wait during server monitoring when opening a connection to a server or checking a server&apos;s status before concluding the server is unavailable&lt;/li&gt;
	&lt;li&gt;serverSelectionTimeoutMS &#8211; this option controls how long the driver will wait to find an available, appropriate server to carry out a database operation; while it is waiting, multiple server monitoring operations may be carried out, each controlled by connectTimeoutMS&lt;/li&gt;
	&lt;li&gt;socketTimeoutMS &#8211;&#160;this option controls how long the driver will wait for a response after sending an ordinary (non-monitoring) database operation before concluding that a network error has occurred&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="894004" author="behackett" created="Tue, 21 Apr 2015 16:48:38 +0000"  >&lt;p&gt;Perhaps what we need here is standard documentation for these two options (connectTimeoutMS and serverSelectionTimeoutMS)? &lt;/p&gt;</comment>
                            <comment id="893982" author="david.golden" created="Tue, 21 Apr 2015 16:23:32 +0000"  >&lt;blockquote&gt;&lt;p&gt;For multi-threaded drivers, no big deal. For single-threaded, crucial.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I think it applies for multi-threaded drivers, too.  Shorter connectTimeout (if used for select with isMaster) means down servers are detected more quickly and thus the topology view is updated more quickly, which means fewer ops possibly routed to a down server.&lt;/p&gt;</comment>
                            <comment id="893978" author="jesse" created="Tue, 21 Apr 2015 16:21:46 +0000"  >&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#socket-timeout-for-monitoring-is-connecttimeoutms&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#socket-timeout-for-monitoring-is-connecttimeoutms&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="893976" author="david.golden" created="Tue, 21 Apr 2015 16:21:31 +0000"  >&lt;p&gt;Let&apos;s imagine my replica set is entirely within a single data center.  I might want a really short connectTimeout so that I detect problems quickly.  On the other hand, imagine my replica set is 50 hosts spread across the world. I need a longer connectTimeout so that I don&apos;t give up talking to servers on the other side of the planet.&lt;/p&gt;

&lt;p&gt;So I don&apos;t think we can pick a default for connection timeouts and then snap off the knob.&lt;/p&gt;

&lt;p&gt;serverSelectTimeout sits on top and covers the timeout across possibly multiple connection/ismaster attempts and needs to be a multiple of connectTimeout to allow multiple attempts before giving up.  serverSectionTimeout is the thing that will affect end-user perceived delay the most, but connectTimeout still affects the latency of the underlying SDAM activities and thus needs to be separately tunable.&lt;/p&gt;</comment>
                            <comment id="893975" author="jesse" created="Tue, 21 Apr 2015 16:21:03 +0000"  >&lt;p&gt;They actually hint drivers about two things. selection timeout is, &quot;how much queueing do I have room for in my application?&quot; connect timeout is, &quot;how fast is my network?&quot; the point of connect timeout is to hint the driver, which never knows whether a server is unresponsive because it&apos;s slow or because it&apos;s down, that I&apos;ve set up my network and I believe a server that doesn&apos;t respond in 5 sec is probably down.&lt;/p&gt;

&lt;p&gt;For multi-threaded drivers, no big deal. For single-threaded, crucial.&lt;/p&gt;</comment>
                            <comment id="893963" author="jblackburn" created="Tue, 21 Apr 2015 16:09:51 +0000"  >&lt;p&gt;Personally I can reason about connectTimeout vs socketTimeout, and when I might want to do either.  ServerSelectTimeout is another axis of configuration that, to me, should be semantically equivalent to connectTimeout. I don&apos;t think the user should want to, or be encourage to tune both.  In naming terms &lt;tt&gt;connectTimeoutMS&lt;/tt&gt; is semantically clearer than &lt;tt&gt;serverSelectionTimeoutMS&lt;/tt&gt;.  Can the driver abstract away this complexity such that tuning the &lt;tt&gt;connectTimeoutMS&lt;/tt&gt; does the right-thing?&lt;/p&gt;</comment>
                            <comment id="893944" author="behackett" created="Tue, 21 Apr 2015 15:54:29 +0000"  >&lt;p&gt;This isn&apos;t about connectTimeoutMS vs. socketTimeoutMS though. This is about serverSelectionTimeoutMS, which will &lt;b&gt;always&lt;/b&gt; dominate connectTimeoutMS from a users perspective, especially in multi-threaded drivers that use a thread per server for monitoring.&lt;/p&gt;</comment>
                            <comment id="893905" author="david.golden" created="Tue, 21 Apr 2015 15:23:33 +0000"  >&lt;p&gt;I think we still want both:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Connect timeout &amp;#8211; used &lt;b&gt;both&lt;/b&gt; for connecting to servers and for SDAM isMaster() calls; this can be set short so things fail fast when network connections go down.&lt;/li&gt;
	&lt;li&gt;Socket timeout &amp;#8211; this can be long, like maxTimeMS; this is how long to wait for regular operations to return a response &lt;b&gt;after&lt;/b&gt; they are sent before concluding that the network is down rather than just that the server is slow.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Put differently: use &quot;connect timeout&quot; for &quot;are you up-or-down&quot; questions, but use &quot;socket timeout&quot; for &quot;are you still thinking?&quot; questions.&lt;/p&gt;
</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="199239">PYTHON-908</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </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_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hs8m2f:</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>