<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:53:01 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>[JAVA-767] connection pool may leak connections on server restart</title>
                <link>https://jira.mongodb.org/browse/JAVA-767</link>
                <project id="10006" key="JAVA">Java Driver</project>
                    <description>&lt;p&gt;On Tue, Feb 19, 2013 at 7:13 PM, Alberto Vilches &amp;lt;vilches@gmail.com&amp;gt; wrote:&lt;br/&gt;
Hi, I&apos;m using Mongodb to log the access in a public Grails application, using Mongodb Java client 2.10.1, and it works fine (we have up to 30 request/second, and every request is logged!).&lt;/p&gt;

&lt;p&gt;Now, we are trying to stress the system, doing some chaos monkey tests, like restart the mongodb in the middle of the day. While the mongodb is restarting, the logs are losts, and this is the behavior expected. When the mongodb is up and running again, the app continues sending logs to the Mongodb. At the beginning, only a few are lost with a timeout, but when the time passes, more and more logs are lost and finally, no logs are send to the Mongo. This is the exception we have:&lt;/p&gt;

&lt;p&gt;org.springframework.data.mongodb.UncategorizedMongoDbException: Connection wait timeout after 120000 ms; nested exception is com.mongodb.DBPortPool$ConnectionWaitTimeOut: Connection wait timeout after 120000 ms&lt;/p&gt;

&lt;p&gt;My Mongodb configuration is this:&lt;br/&gt;
grails.mongo.host=mongo.mundoreader.local&lt;br/&gt;
grails.mongo.options.autoConnectRetry=true&lt;br/&gt;
grails.mongo.options.connectTimeout=300&lt;br/&gt;
grails.mongo.options.connectionsPerHost=40&lt;br/&gt;
grails.mongo.options.maxAutoConnectRetryTime=5&lt;br/&gt;
grails.mongo.options.maxWaitTime=120000&lt;br/&gt;
grails.mongo.options.threadsAllowedToBlockForConnectionMultiplier=50&lt;/p&gt;

&lt;p&gt;I&apos;m not sure, but I have the felling the connection pool keep the old and broken connections alive, so when the Mongodb starts again, the connection pool doesn&apos;t have any connection free to connect to it again, and wait forever to the broken and old connection finish. Like the sql connection pool, the Mongo connection pool should check if a connection is broken, and remove it from the pool, creating a new one, but I think that&apos;s not happening.&lt;/p&gt;

&lt;p&gt;&#191;Somebody have any idea about this? Thank you!&lt;/p&gt;

&lt;p&gt;&amp;#8211; &lt;br/&gt;
Un saludo.&lt;br/&gt;
Alberto Vilches&lt;br/&gt;
&lt;a href=&quot;http://albertovilches.com&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://albertovilches.com&lt;/a&gt;&lt;br/&gt;
Twitter: @albertovilches&lt;/p&gt;</description>
                <environment></environment>
        <key id="65972">JAVA-767</key>
            <summary>connection pool may leak connections on server restart</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="2" iconUrl="https://jira.mongodb.org/images/icons/priorities/critical.svg">Critical - P2</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="jeff.yemin@mongodb.com">Jeffrey Yemin</assignee>
                                    <reporter username="jeff.yemin@mongodb.com">Jeffrey Yemin</reporter>
                        <labels>
                    </labels>
                <created>Thu, 21 Feb 2013 13:17:25 +0000</created>
                <updated>Tue, 31 Mar 2015 20:10:09 +0000</updated>
                            <resolved>Tue, 25 Jun 2013 17:54:07 +0000</resolved>
                                    <version>2.10.1</version>
                                    <fixVersion>3.0.0</fixVersion>
                                    <component>Connection Management</component>
                                        <votes>4</votes>
                                    <watches>8</watches>
                                                                                                                <comments>
                            <comment id="869538" author="jeff.yemin" created="Tue, 31 Mar 2015 20:10:09 +0000"  >&lt;p&gt;Closing all resolved 3.0.0 issues, as 3.0.0 has been tagged and released.&lt;/p&gt;</comment>
                            <comment id="394682" author="jeff.yemin" created="Fri, 2 Aug 2013 18:16:23 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=h0nig&quot; class=&quot;user-hover&quot; rel=&quot;h0nig&quot;&gt;h0nig&lt;/a&gt; Which idea were you referring to?  &lt;/p&gt;

&lt;p&gt;The problem as I see it is that there is always a chance that the connection pool will return a broken connection.  If we have a background thread that sends a ping to every connection every minute, you could still get a bad connection.  Whatever we do only decreases the chance of it happening.  By using maxLifeTime and maxIdleTime to control connection life times, we put it into the hands of the developer, who knows the characteristics of the networking environment in which the application is running, e.g. load balancers that shut down connections, etc.&lt;/p&gt;</comment>
                            <comment id="393664" author="fabiangebert" created="Thu, 1 Aug 2013 16:59:09 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jeff.yemin&quot; class=&quot;user-hover&quot; rel=&quot;jeff.yemin&quot;&gt;jeff.yemin&lt;/a&gt; done so with &lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-915&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/JAVA-915&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="393648" author="h0nig" created="Thu, 1 Aug 2013 16:44:36 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jeff.yemin&quot; class=&quot;user-hover&quot; rel=&quot;jeff.yemin&quot;&gt;jeff.yemin&lt;/a&gt; thats a good idea, but there is still the chance that the connection pool will return a broken connection and will close it after the socketexception is thrown (as far as i understood your comment &amp;amp; code). with your change you just minimized the problem to the first connection and the fact that the other connections will be closed after the error is detected. there is still the idea of a background thread that checks the connections (and maybe handles the max* attributes)&lt;/p&gt;</comment>
                            <comment id="393620" author="jeff.yemin" created="Thu, 1 Aug 2013 15:55:22 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=h0nig&quot; class=&quot;user-hover&quot; rel=&quot;h0nig&quot;&gt;h0nig&lt;/a&gt; I prefer specifying maxIdleTime and maxLifeTime, as discussed in &lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-710&quot; title=&quot;Support max connection idle time and max connection life time&quot; class=&quot;issue-link&quot; data-issue-key=&quot;JAVA-710&quot;&gt;&lt;del&gt;JAVA-710&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="393618" author="jeff.yemin" created="Thu, 1 Aug 2013 15:53:50 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=fabiangebert&quot; class=&quot;user-hover&quot; rel=&quot;fabiangebert&quot;&gt;fabiangebert&lt;/a&gt; This bug was reported against the 2.10 version of the driver, so it&apos;s not likely to be what your encountering there, as I understand it you believe the problem in GPMONGO-307 as a regression introduced in 2.11.  Would you mind opening a new issue related to your findings in GPMONGODB-307?&lt;/p&gt;</comment>
                            <comment id="393545" author="fabiangebert" created="Thu, 1 Aug 2013 14:21:46 +0000"  >&lt;p&gt;is this related to &lt;a href=&quot;http://jira.grails.org/browse/GPMONGODB-307&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://jira.grails.org/browse/GPMONGODB-307&lt;/a&gt; ?&lt;br/&gt;
It doesn&apos;t happen with the 2.10.x versions&lt;/p&gt;</comment>
                            <comment id="367975" author="h0nig" created="Wed, 26 Jun 2013 08:45:44 +0000"  >&lt;p&gt;do you think that is also a good idea to have a thread running on the background that is checking the connections periodically? i think yes&lt;/p&gt;</comment>
                            <comment id="367496" author="jeff.yemin" created="Tue, 25 Jun 2013 17:54:07 +0000"  >&lt;p&gt;See&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/connection/impl/DefaultConnectionProvider.java&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/connection/impl/DefaultConnectionProvider.java&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;In PooledConnection, the wrapped connections is discarded if it&apos;s been closed, which will be the case if there was a socket exception.&lt;/p&gt;</comment>
                            <comment id="367000" author="jeff.yemin" created="Tue, 25 Jun 2013 04:09:25 +0000"  >&lt;p&gt;In 3.0.x branch, closed connections (which happens on IOException) are discarded.&lt;/p&gt;</comment>
                            <comment id="326415" author="h0nig" created="Thu, 2 May 2013 09:10:10 +0000"  >&lt;p&gt;got the same problem. there should be a precheck on returning the port from the pool. &lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/pull/113&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/pull/113&lt;/a&gt;&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrmag7:</customfieldvalue>

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