<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:48:03 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-4375] Connection pruner is too aggressive</title>
                <link>https://jira.mongodb.org/browse/CSHARP-4375</link>
                <project id="10041" key="CSHARP">C# Driver</project>
                    <description>&lt;p&gt;We recently updated from mongodb server 4.2 / mongodb driver 2.12.5 to mongodb server 5.0 / mongodb driver 2.17.0, after which we have observed a rise in timeouts from our applications, and a sawtooth-shape in our open connections graph. (We use an EventSubscriber to keep track of open connections.)&lt;/p&gt;

&lt;p&gt;After some investigation, we see that there is a significant change in how connections are maintained in the ExclusiveConnectionPool.&lt;/p&gt;

&lt;p&gt;v2.12.5 would prune 1 connection at a time (note the break statement in the loop):&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-csharp-driver/blob/v2.12.5/src/MongoDB.Driver.Core/Core/ConnectionPools/ExclusiveConnectionPool.cs#L818&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-csharp-driver/blob/v2.12.5/src/MongoDB.Driver.Core/Core/ConnectionPools/ExclusiveConnectionPool.cs#L818&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;whilst newer versions will quite aggressively remove all expired connections:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/mongo-csharp-driver/blob/v2.18.0/src/MongoDB.Driver.Core/Core/ConnectionPools/ExclusiveConnectionPool.Helpers.cs#L707&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-csharp-driver/blob/v2.18.0/src/MongoDB.Driver.Core/Core/ConnectionPools/ExclusiveConnectionPool.Helpers.cs#L707&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;This is a problem for our applications, which require many open connections (100) at all time. (Our applications handle high spikes of traffic, with quiet periods in between.)&lt;/p&gt;

&lt;p&gt;During quiet periods, MaintenanceHelper (v2.17.0) will periodically remove all existing connections, and spend some time creating new ones. When a traffic spike hits our application at the same time, the application will not be able to serve incoming requests, and we get lots of timeouts.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;v2.12.5 of the driver would remove one connection, open one connection, remove one, open one etc, which results in the application always having available open connections.&lt;/p&gt;

&lt;p&gt;v2.17.0 removes all connections at once, which renders our application useless for the next (15-30) seconds.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;We rely on MaintenanceHelper maintaining connections &quot;the old way&quot;, or we cannot use the driver.&lt;/p&gt;</description>
                <environment></environment>
        <key id="2163955">CSHARP-4375</key>
            <summary>Connection pruner is too aggressive</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="13203">Gone away</resolution>
                                        <assignee username="boris.dogadov@mongodb.com">Boris Dogadov</assignee>
                                    <reporter username="hans.olav.loftum@nrk.no">Hans Olav Loftum</reporter>
                        <labels>
                    </labels>
                <created>Fri, 21 Oct 2022 07:20:38 +0000</created>
                <updated>Fri, 27 Oct 2023 19:56:01 +0000</updated>
                            <resolved>Wed, 16 Nov 2022 12:00:41 +0000</resolved>
                                                                                        <votes>0</votes>
                                    <watches>7</watches>
                                                                                                                <comments>
                            <comment id="4986199" author="dbeng-pm-bot" created="Wed, 16 Nov 2022 12:00:43 +0000"  >&lt;p&gt;There hasn&apos;t been any recent activity on this ticket, so we&apos;re resolving it. Thanks for reaching out! Please feel free to comment on this if you&apos;re able to provide more information.&lt;/p&gt;</comment>
                            <comment id="4939713" author="JIRAUSER1257742" created="Mon, 31 Oct 2022 15:02:19 +0000"  >&lt;p&gt;Hi &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jean.coulon%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;jean.coulon@mongodb.com&quot;&gt;jean.coulon@mongodb.com&lt;/a&gt;&#160;&lt;/p&gt;

&lt;p&gt;Yes, I would suggest experimenting with values of 10, 20, 100 (or even higher if needed)&lt;br/&gt;
This parameter limits the number of simultaneously created connections by each client to limit the load on the server.&lt;br/&gt;
Therefore the optimal value depends on the total number of clients and the amount of connections that server can establish simultaneously.&#160;&lt;/p&gt;

&lt;p&gt;If that does not work, it would be helpful to get a repro simulating the load and validating the expected response time.&lt;br/&gt;
For example repro the initiates 1000 simultaneous requests that take 1 min on older version, and timeout on the new version.&lt;/p&gt;</comment>
                            <comment id="4924016" author="JIRAUSER1257742" created="Mon, 24 Oct 2022 22:35:35 +0000"  >&lt;p&gt;Hello &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=andreas.knudsen%40nrk.no&quot; class=&quot;user-hover&quot; rel=&quot;andreas.knudsen@nrk.no&quot;&gt;andreas.knudsen@nrk.no&lt;/a&gt; and &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=hans.olav.loftum%40nrk.no&quot; class=&quot;user-hover&quot; rel=&quot;hans.olav.loftum@nrk.no&quot;&gt;hans.olav.loftum@nrk.no&lt;/a&gt;&#160;&lt;/p&gt;

&lt;p&gt;Thank you for identifying the specific driver version range. &lt;br/&gt;
One reason for such behavior differences might be the introduction of &lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-3305&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;maxConnecting&lt;/a&gt; functionality. Default value of 2 resulted in behavior change under load for some applications, like &lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-3885&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;.&lt;br/&gt;
I would recommend fine-tuning this parameter for your application needs.&lt;/p&gt;

&lt;p&gt;If this does not help, it would be great to have a repro demonstrating performance degradation in a certain scenario if possible. As you have mentioned the provided test application outputs the connections, but it does not replicate the traffic load issue.&lt;/p&gt;

&lt;p&gt;Some notes:&lt;br/&gt;
The logic of connection pool populating and pruning is shared among all the drivers and is described &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.rst#background-thread&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;here&lt;/a&gt;&lt;br/&gt;
We can evaluate optimizations in this area, but any improvement must be considered against multiple scenarios for various drivers.&lt;/p&gt;</comment>
                            <comment id="4923223" author="JIRAUSER1271583" created="Mon, 24 Oct 2022 18:26:36 +0000"  >&lt;p&gt;I have just run a few load tests with a modified ExclusiveConnectionPool.Helpers.cs that would start pruning connections while they still had half their lifetime/idle-time left and would never prune more than 25% at a time&lt;/p&gt;

&lt;p&gt;I&apos;m sad to say that it didn&apos;t have any noticeable effect on the system under heavy load,&lt;/p&gt;

&lt;p&gt;I ran tests multiple times both with and without event subscription but I could not notice any difference between those configurations.&lt;/p&gt;

&lt;p&gt;I did however notice that the CPU spiked quite a bit on the DB server and the connection count went down (observed with the Real Time metrics in Atlas)&#160;&lt;/p&gt;

&lt;p&gt;Can a saturated server be the answer to why the connection count is plummeting?&#160;&lt;/p&gt;

&lt;p&gt;I might try to downgrade the DB to MongoDB 4.2 tomorrow and run a new barrage of tests against it to see if we get the same CPU spikes on 4.2&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="4922687" author="JIRAUSER1271582" created="Mon, 24 Oct 2022 16:11:12 +0000"  >&lt;p&gt;@Dmitry Lukyanov&lt;/p&gt;

&lt;p&gt;One of the criterions Andreas is referring to is this:&lt;br/&gt;
&lt;a href=&quot;https://github.com/nrkno/mongo-csharp-driver/blob/master/src/MongoDB.Driver.Core/Core/Connections/BinaryConnection.cs#L113&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/nrkno/mongo-csharp-driver/blob/master/src/MongoDB.Driver.Core/Core/Connections/BinaryConnection.cs#L113&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;BinaryConnection is &quot;just as&quot; expired whether it has been idle for too long, or if it has exceeded max lifetime.&lt;br/&gt;
But there is no way to tell that &quot;this connection is getting old, and should be pensioned&quot;&lt;/p&gt;

&lt;p&gt;Imagine that an IConnection could get &quot;old&quot; after idling for some time - say MaxIdleTime * 0.75. Then it would be a candidate for pruning, even though it is not yet expired. That way, pruning/replacing it would start before the connection is useless.&lt;/p&gt;</comment>
                            <comment id="4922462" author="JIRAUSER1271583" created="Mon, 24 Oct 2022 15:21:47 +0000"  >&lt;p&gt;We have reproduced the problems in 2.13.3 and 2.15 so it was introduced between 2.12.5 and 2.13.3&lt;/p&gt;</comment>
                            <comment id="4922460" author="JIRAUSER1271583" created="Mon, 24 Oct 2022 15:20:52 +0000"  >&lt;p&gt;I agree that IF a connection has become unusable THEN it should be removed as fast as possible. My point is to introduce a new even stricter criterion used for pruning.&lt;/p&gt;

&lt;p&gt;with the current setup there is no way to preemptively stock up on new connections until AFTER they have already become unusable..&lt;/p&gt;

&lt;p&gt;If this was a refridgerator, would you not start to buy new milk BEFORE the expiry date? otherwise there WOULD GUARANTEED be a morning where there was no milk for the cereal &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;-A&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="4921839" author="dmitry.lukyanov" created="Mon, 24 Oct 2022 12:27:44 +0000"  >&lt;p&gt;Thanks &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=hans.olav.loftum%40nrk.no&quot; class=&quot;user-hover&quot; rel=&quot;hans.olav.loftum@nrk.no&quot;&gt;hans.olav.loftum@nrk.no&lt;/a&gt; , we will look at your repro.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;to connect to mongo with the well-known&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Yes, a timeout exception is well-known, but exception type itself says not much, we need to get servers statuses including heartbeat exceptions. So, we need full timeout exceptions descriptions (ie that triggered not because CancellationToken).&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;and requests will queue up, leading to high memory, CPU usage and thread exhaustion.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;this looks unexpected.., we will try to get this behavior from your repro.&lt;/p&gt;

&lt;p&gt;Hey &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=andreas.knudsen%40nrk.no&quot; class=&quot;user-hover&quot; rel=&quot;andreas.knudsen@nrk.no&quot;&gt;andreas.knudsen@nrk.no&lt;/a&gt; ,&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;to avoid ending up with very few connections available for a sudden burst of traffic&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;if a connection is expired (ie perished) no one can use it, so at this point it looks unlikely that removing them at once can make any difference.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;Do not use the same criterion for pruning as for discarding connections during Aquire&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;a connection can become expired in different ways, for example it became expired if the current server is unhealthy, so I don&apos;t think that introducing a new criteria can help with your issue.&lt;/p&gt;

&lt;p&gt;For now, we will look at your repro to reproduce your issue and we&apos;ll get back to you.&lt;/p&gt;

&lt;p&gt;Some initial suspicions that you can check to speed up investigating:&lt;/p&gt;

&lt;p&gt;1. It might be related to how you use EventsLogger. It would be good if you can validate this issue without the event subscriber configured.&lt;br/&gt;
2. It might be related to pool changes introduced in 2.16 released. So, It would be good if you can check your application behavior with pre 2.16 driver, like 2.15.1&lt;/p&gt;</comment>
                            <comment id="4921653" author="JIRAUSER1271583" created="Mon, 24 Oct 2022 10:44:14 +0000"  >&lt;p&gt;Hi there.&#160;&lt;/p&gt;

&lt;p&gt;I believe I know what is happening here:&#160;&lt;/p&gt;

&lt;p&gt;There are 2 ways expired (both maxidletime and maxlifetime) connections are removed from the connection pool:&#160;&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;ExclusiveConnectionPool.ListConnectionHolder.Prune(..)
	&lt;ul&gt;
		&lt;li&gt;Prunes all 100% of expired connections every MaintenanceInterval&lt;/li&gt;
		&lt;li&gt;After it is done with pruning it will then rebuild connections back up to minconnections&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;ExclusiveConnectionPool.ListConnectionHolder.Aquire(..)
	&lt;ul&gt;
		&lt;li&gt;Prunes all expired connections it discovers while looking for a new connection to aquire&#160;&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Unfortunately both of these mechanisms use the same criterion to determine if a connection should be discarded.&lt;/p&gt;

&lt;p&gt;There are two problems with this setup:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Pruning connections is liable to some times take the connection count all the way down to 0 connections when under heavy load (since it is possible that all connections will have expired at some time during the maintenanceinterval)
	&lt;ul&gt;
		&lt;li&gt;If the maintenance interval is long and the maxlifetime is short&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;the pruning process risks not having anything to prune because by the time it starts the Aquire-process might have removed all the candidates for pruning preemptively
	&lt;ul&gt;
		&lt;li&gt;More likely if the maintenance interval is long&#160;&lt;/li&gt;
		&lt;li&gt;If this happens then the connection count may also very well for a short while go to 0 since the Aquire process doesn&apos;t do anything special to prevent it.&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I propose the following 2 changes:&#160;&lt;/p&gt;

&lt;p&gt;1) Do not use the same criterion for pruning as for discarding connections during Aquire&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;A simple way to do this is to say that connections become available for pruning after maxidletime/2 and maxlifetime/2&lt;/li&gt;
	&lt;li&gt;a more flexible way is to introduce a separate config value for this&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;2) Do not prune every connection that can be pruned in one go (to avoid ending up with very few connections available for a sudden burst of traffic)&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;A simple way to do this is to max prune Math.Max(1, _settings.MinConnections / 4) at a time before refilling connections
	&lt;ul&gt;
		&lt;li&gt;Ensuring that you always have at least 75% capacity available&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;A more flexible way is to introduce separate config value for this&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;I will submit a PR with these two changes made (both done the &quot;simple&quot; way as I&apos;m not sure having the extra flexibility adds much value)&lt;/p&gt;

&lt;p&gt;-Andreas&lt;/p&gt;</comment>
                            <comment id="4921491" author="JIRAUSER1271582" created="Mon, 24 Oct 2022 08:27:00 +0000"  >&lt;p&gt;And yes: Our application uses MongoClient as a single instance.&lt;/p&gt;</comment>
                            <comment id="4921462" author="JIRAUSER1271582" created="Mon, 24 Oct 2022 07:57:23 +0000"  >&lt;p&gt;Here are a couple of the stacktraces we got.&lt;/p&gt;


&lt;p&gt;Our application uses an internal timeout, which will cancel after a certain amount of time. If we don&apos;t do that, all incoming requests will spend 15 seconds trying to connect to mongo with the well-known&lt;br/&gt;
&lt;tt&gt;A timeout occured after 15000ms selecting a server using CompositeServerSelector&lt;/tt&gt;&lt;br/&gt;
and requests will queue up, leading to high memory, CPU usage and thread exhaustion.&lt;/p&gt;

&lt;p&gt;Therefore, all exceptions have the message &quot;The operation was canceled&quot;.&lt;/p&gt;

&lt;p&gt;(Note: Our application has run like this with mongodb 4.2 and mongo driver 2.12.5 for a long time, without big connection issues.)&lt;/p&gt;


&lt;p&gt;1.&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;The operation was canceled.&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;at System.Threading.CancellationToken.ThrowOperationCanceledException()&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Clusters.Cluster.WaitForDescriptionChangedHelper.HandleCompletedTask(Task completedTask)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Clusters.Cluster.WaitForDescriptionChangedAsync(IServerSelector selector, ClusterDescription description, Task descriptionChangedTask, TimeSpan timeout, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Clusters.Cluster.SelectServerAsync(IServerSelector selector, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Clusters.IClusterExtensions.SelectServerAndPinIfNeededAsync(ICluster cluster, ICoreSessionHandle session, IServerSelector selector, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Bindings.ReadPreferenceBinding.GetReadChannelSourceAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Operations.RetryableReadContext.InitializeAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Operations.RetryableReadContext.CreateAsync(IReadBinding binding, Boolean retryRequested, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Operations.FindOperation`1.ExecuteAsync(IReadBinding binding, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.OperationExecutor.ExecuteReadOperationAsync&lt;span class=&quot;error&quot;&gt;&amp;#91;TResult&amp;#93;&lt;/span&gt;(IReadBinding binding, IReadOperation`1 operation, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.MongoCollectionImpl`1.ExecuteReadOperationAsync&lt;span class=&quot;error&quot;&gt;&amp;#91;TResult&amp;#93;&lt;/span&gt;(IClientSessionHandle session, IReadOperation`1 operation, ReadPreference readPreference, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.MongoCollectionImpl`1.UsingImplicitSessionAsync&lt;span class=&quot;error&quot;&gt;&amp;#91;TResult&amp;#93;&lt;/span&gt;(Func`2 funcAsync, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at Our code&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;2.&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;The operation was canceled.&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;at System.Threading.CancellationToken.ThrowOperationCanceledException()&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Misc.SemaphoreSlimSignalable.IsSignaled(CancellationTokenSource signalTokenSource, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Misc.SemaphoreSlimSignalable.WaitSignaledAsync(TimeSpan timeout, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.ConnectionPools.ExclusiveConnectionPool.ConnectionCreator.CreateOpenedOrReuseAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.ConnectionPools.ExclusiveConnectionPool.AcquireConnectionHelper.AcquireConnectionAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.ConnectionPools.ExclusiveConnectionPool.AcquireConnectionAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Servers.Server.GetChannelAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Operations.RetryableReadContext.InitializeAsync(CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Operations.RetryableReadContext.CreateAsync(IReadBinding binding, Boolean retryRequested, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.Core.Operations.FindOperation`1.ExecuteAsync(IReadBinding binding, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.OperationExecutor.ExecuteReadOperationAsync&lt;span class=&quot;error&quot;&gt;&amp;#91;TResult&amp;#93;&lt;/span&gt;(IReadBinding binding, IReadOperation`1 operation, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.MongoCollectionImpl`1.ExecuteReadOperationAsync&lt;span class=&quot;error&quot;&gt;&amp;#91;TResult&amp;#93;&lt;/span&gt;(IClientSessionHandle session, IReadOperation`1 operation, ReadPreference readPreference, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at MongoDB.Driver.MongoCollectionImpl`1.UsingImplicitSessionAsync&lt;span class=&quot;error&quot;&gt;&amp;#91;TResult&amp;#93;&lt;/span&gt;(Func`2 funcAsync, CancellationToken cancellationToken)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160;at Our code&lt;/tt&gt;&lt;/p&gt;</comment>
                            <comment id="4921439" author="JIRAUSER1271582" created="Mon, 24 Oct 2022 07:35:20 +0000"  >&lt;p&gt;Test application here:&lt;br/&gt;
&lt;a href=&quot;https://github.com/nrkno/mongo-connection-test&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/nrkno/mongo-connection-test&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;It is a console app that just idles, and prints number of connections to console.&lt;/p&gt;</comment>
                            <comment id="4919174" author="dmitry.lukyanov" created="Fri, 21 Oct 2022 17:20:05 +0000"  >&lt;p&gt;Hey &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=hans.olav.loftum%40nrk.no&quot; class=&quot;user-hover&quot; rel=&quot;hans.olav.loftum@nrk.no&quot;&gt;hans.olav.loftum@nrk.no&lt;/a&gt; , thank you for your report.&lt;/p&gt;

&lt;p&gt;We&apos;re investigating your case. Meanwhile can you provide/try the following:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;&quot;we get lots of timeouts.&quot; - can you provide these exceptions with stacktrace?&lt;/li&gt;
	&lt;li&gt;It would be good to get a repro if possible, this will help a lot with investigating. Also, can you provide your use case, which operations fail, whether threads are involved and etc.&lt;/li&gt;
	&lt;li&gt;Does this behavior happen constantly under load? Has it ever happened without load?&lt;/li&gt;
	&lt;li&gt;You mentioned you configure EventSubscriber, can you provide its code and in general which options you specify during creating MongoClient? Can you check this issue without EventSubscriber configured?&lt;/li&gt;
	&lt;li&gt;&#160;Do you use MongoClient as singleton?&lt;/li&gt;
	&lt;li&gt;Also, it would be good if you can validate this behavior in pre-2.16 driver, like in 2.15.1.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Thanks in advance.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                    <customfield id="customfield_13552" key="com.go2group.jira.plugin.crm:crm_generic_field">
                        <customfieldname>Case</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[[5006R00001oms4HQAQ]]]></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_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|i0xk48:</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>