<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 05:43:24 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-58026] Omitted FTDC sections cause frequent schema changes that limit FTDC retention</title>
                <link>https://jira.mongodb.org/browse/SERVER-58026</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-30888&quot; title=&quot;Have FTDC code paths obtain locks with a timeout.&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-30888&quot;&gt;&lt;del&gt;SERVER-30888&lt;/del&gt;&lt;/a&gt; introduces the possibility that FTDC might be missing serverStatus.wiredTiger, serverStatus.oplog, and/or local.oplog.rs.stats sections.  &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-48221&quot; title=&quot;Shut down ftdc after storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-48221&quot;&gt;&lt;del&gt;SERVER-48221&lt;/del&gt;&lt;/a&gt; may have introduced a similar issue for the serverStatus.oplogTruncation and serverStatus.encryptionAtRest secitions. There might be other similar potentially omitted sections that I didn&apos;t find.&lt;/p&gt;

&lt;p&gt;This can cause frequent schema changes that reduce FTDC compression efficiency and limit retention. For example, in one deployment FTDC retention was reduced to less than 2 days, compared to a typical retention of closer to a week. The missing data can also cause us to miss important events in FTDC.&lt;/p&gt;

&lt;p&gt;It looks to me like the primary issue might be that we&apos;re using an extremely short timeout for acquiring the locks needed for collecting these sections, so it might be sufficient to increase the timeout to a substantial fraction of a second, although that needs verification.&lt;/p&gt;</description>
                <environment></environment>
        <key id="1795528">SERVER-58026</key>
            <summary>Omitted FTDC sections cause frequent schema changes that limit FTDC retention</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="10038" iconUrl="https://jira.mongodb.org/images/icons/subtask.gif" description="">Backlog</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="backlog-server-security">Backlog - Security Team</assignee>
                                    <reporter username="bruce.lucas@mongodb.com">Bruce Lucas</reporter>
                        <labels>
                    </labels>
                <created>Wed, 23 Jun 2021 17:54:41 +0000</created>
                <updated>Tue, 7 Nov 2023 18:25:27 +0000</updated>
                                            <version>4.4.3</version>
                    <version>5.0.0-rc0</version>
                                                                        <votes>0</votes>
                                    <watches>15</watches>
                                                                                                                <comments>
                            <comment id="5019517" author="bruce.lucas@10gen.com" created="Wed, 30 Nov 2022 17:27:04 +0000"  >&lt;p&gt;Thanks for the detail.&lt;/p&gt;

&lt;p&gt;Yes a few or a few dozen schema changes at some major transition in system state (like startup) is not a problem; the problem comes from repeated sustained schema changes throughout operation. There are already by the way generally a few schema changes during startup as various subsystems come on line and add their data to serverStatus.&lt;/p&gt;</comment>
                            <comment id="5019140" author="daniel.gottlieb@10gen.com" created="Wed, 30 Nov 2022 16:03:29 +0000"  >&lt;blockquote&gt;&lt;p&gt;&lt;br/&gt;
will allow FTDC to no longer take the global lock because it will no longer be needed for coordination with WT startup and shutdown, is that correct?&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Yes.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;If so, is it the case that that change (no longer taking the global lock for FTDC) will happen as part of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt;, or is that an additional change that would need to happen via this ticket?&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I&apos;m rather convinced it&apos;s impossible to do &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt; (and satisfy the desired outcome of gathering FTDC at startup/shutdown) while still having FTDC grab locks (the POC that I&apos;ve misplaced demonstrated its viability) . &lt;/p&gt;

&lt;p&gt;For more of a formal argument: startup/shutdown/rollback will continue to take a global lock (such that the system cannot attempt to access WT for reads/writes). If &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt; succeeds in getting FTDC data during startup/shutdown/rollback &amp;#8211; it must not take the global lock. That said, &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt; could be broken down/redefined into something like &quot;use WT&apos;s new API&quot; and stop short of funneling the data into FTDC. Thus I&apos;ve marked this as &quot;depends on&quot; and not &quot;duplicates&quot;.&lt;/p&gt;

&lt;p&gt;Given the title of this ticket about FTDC, schema changes, one thing &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt; will likely introduce is the possibility for schema changes during startup. Because the storage engine starts up before other systems that have FTDC hooks (e.g: replication), we&apos;ll want to output storage stats before we&apos;ve even constructed those objects that come into existence later in the startup procedure.&lt;/p&gt;

&lt;p&gt;The number of schema redefines introduced should be constant (at most one redefine per module that registers an FTDC handler &amp;#8211; which is bounded for any given compile/set of startup options). And I don&apos;t expect any additional schema redefines after startup due to this change.&lt;/p&gt;

&lt;p&gt;I assumed that limited amount of new potential schema redefines would be acceptable.&lt;/p&gt;</comment>
                            <comment id="5018856" author="bruce.lucas@10gen.com" created="Wed, 30 Nov 2022 15:09:37 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=daniel.gottlieb%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;daniel.gottlieb@mongodb.com&quot;&gt;daniel.gottlieb@mongodb.com&lt;/a&gt;, if I understand correctly that is because &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt; will allow FTDC to no longer take the global lock because it will no longer be needed for coordination with WT startup and shutdown, is that correct? If so, is it the case that that change (no longer taking the global lock for FTDC) will happen as part of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt;, or is that an additional change that would need to happen via this ticket?&lt;/p&gt;</comment>
                            <comment id="5018731" author="daniel.gottlieb@10gen.com" created="Wed, 30 Nov 2022 14:52:04 +0000"  >&lt;p&gt;I&apos;m leaving this open for visibility, but I think with (the linked) &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-70031&quot; title=&quot;Collect WiredTiger statistics for FTDC during startup and shutdown&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-70031&quot;&gt;SERVER-70031&lt;/a&gt;, the goal of this ticket will be satisfied. Or at least the goal that&apos;s applicable to the storage side of FTDC.&lt;/p&gt;</comment>
                            <comment id="4092899" author="louis.williams" created="Wed, 29 Sep 2021 20:51:02 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=bruce.lucas&quot; class=&quot;user-hover&quot; rel=&quot;bruce.lucas&quot;&gt;bruce.lucas&lt;/a&gt;, yes that is my proposal. I think there is a longer-term solution here that would need to be investigated in-depth. I think that is out of the scope of this ticket since our priority is to increase the retention period for FTDC by avoiding schema changes.&lt;/p&gt;</comment>
                            <comment id="4092209" author="bruce.lucas@10gen.com" created="Wed, 29 Sep 2021 16:51:26 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt;&#160;to make sure I understand the options are&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;current situation: applyOps (or other commands that acquire global lock) cause some sections to be omitted (causing a schema change). Per the opening comment, this is at least&#160;serverStatus.wiredTiger, serverStatus.oplog, and/or local.oplog.rs.stats (and possibly others).&lt;/li&gt;
	&lt;li&gt;proposed solution: don&apos;t emit any samples when global lock can&apos;t be obtained in a timely manner, effectively omitting all sections (but not causing a schema change). This is effectively reverting&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-30888&quot; title=&quot;Have FTDC code paths obtain locks with a timeout.&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-30888&quot;&gt;&lt;del&gt;SERVER-30888&lt;/del&gt;&lt;/a&gt;?&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="4090618" author="louis.williams" created="Tue, 28 Sep 2021 21:58:21 +0000"  >&lt;p&gt;It turns our that introducing a new synchronization mechanism between FTDC and shutdown is rather straightforward. This simple solution allows us to avoid schema changes except for the shutdown case.&lt;/p&gt;

&lt;p&gt;What&apos;s hard is allowing these problematic FTDC sections to avoid taking the Global lock. Allowing certain operations to skip the global lock requires evaluating all of the places we take the Global X lock and determine whether this is safe or also needs to be synchronized as well. I think there&apos;s quite a larger discussion to be had here about the purpose of the global lock and this work seems much riskier.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=bruce.lucas&quot; class=&quot;user-hover&quot; rel=&quot;bruce.lucas&quot;&gt;bruce.lucas&lt;/a&gt;, would you be willing to accept the more straightforward change that blocks FTDC sections on the Global X lock instead of omitting these sections?&lt;/p&gt;</comment>
                            <comment id="4086544" author="louis.williams" created="Mon, 27 Sep 2021 14:56:31 +0000"  >&lt;p&gt;I withdrew my code review because it effectively returns incorrect results for FTDC, which is not desirable behavior. I&apos;m going to explore the alternative of introducing a synchronization mechanism just between FTDC and shutdown.&lt;/p&gt;</comment>
                            <comment id="4080618" author="bruce.lucas@10gen.com" created="Thu, 23 Sep 2021 14:40:43 +0000"  >&lt;p&gt;Not sure, but &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-60168&quot; title=&quot;Allow serverStatus reading data during the RECOVERING member state&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-60168&quot;&gt;SERVER-60168&lt;/a&gt; might also be addressed by such a mechanism.&lt;/p&gt;</comment>
                            <comment id="4080342" author="bruce.lucas@10gen.com" created="Thu, 23 Sep 2021 13:23:34 +0000"  >&lt;blockquote&gt;
&lt;p&gt;Anything that FTDC needs to avoid conflicting with shutdown will also be needed by applyOps&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I&apos;m not following. There&apos;s no reason that FTDC (including sections that access the storage engine) can&apos;t be collected during applyOps, correct? If so, doesn&apos;t that mean that the problem can be solved by introducing an additional coordination mechanism that prohibits collecting certain FTDC sections &lt;em&gt;only&lt;/em&gt; when that&apos;s not permissible, in particular during shutdown?&lt;/p&gt;</comment>
                            <comment id="4048258" author="louis.williams" created="Thu, 9 Sep 2021 18:44:18 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=bruce.lucas&quot; class=&quot;user-hover&quot; rel=&quot;bruce.lucas&quot;&gt;bruce.lucas&lt;/a&gt; the problem is that the global lock is what is used to coordinate shutdown. Anything that FTDC needs to avoid conflicting with shutdown will also be needed by applyOps, so we don&apos;t have many options here. Would it be acceptable to revert the change that allows FTDC to run after storage engine shutdown?&lt;/p&gt;</comment>
                            <comment id="4048199" author="connie.chen" created="Thu, 9 Sep 2021 18:21:38 +0000"  >&lt;p&gt;We should also consider inserting dummy fields to avoid schema changes.&lt;/p&gt;</comment>
                            <comment id="4047133" author="bruce.lucas@10gen.com" created="Thu, 9 Sep 2021 13:07:44 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt; that my help some, but if my &lt;a href=&quot;#comment-3908608&quot; target=&quot;_blank&quot; rel=&quot;noopener&quot;&gt;comment&lt;/a&gt; (&quot;It appears this is taking several seconds to acquire&quot;) is accurate, I&apos;m not sure a timeout of 100ms to 1s will be that helpful.&lt;/p&gt;

&lt;p&gt;I wonder if a fix whereby FTDC uses something other than the global lock to coordinate with shutdown is possible.&lt;/p&gt;</comment>
                            <comment id="4045846" author="louis.williams" created="Wed, 8 Sep 2021 20:09:35 +0000"  >&lt;p&gt;After talking with &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kelsey.schubert&quot; class=&quot;user-hover&quot; rel=&quot;kelsey.schubert&quot;&gt;kelsey.schubert&lt;/a&gt; the Execution team will try to do something to avoid frequent FTDC schema changes.&lt;/p&gt;

&lt;p&gt;For FTDC sections that acquire the Global lock, we will impose a higher timeout, maybe something on the order of 100ms to 1s. The goal is to give FTDC a better chance of collecting statistics to avoid a schema change, even if that introduces a temporary stall. We need a timeout, otherwise, FTDC would block shutdown indefinitely.&lt;/p&gt;</comment>
                            <comment id="3921112" author="kaloian.manassiev" created="Wed, 7 Jul 2021 17:31:41 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kelsey.schubert&quot; class=&quot;user-hover&quot; rel=&quot;kelsey.schubert&quot;&gt;kelsey.schubert&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=bruce.lucas&quot; class=&quot;user-hover&quot; rel=&quot;bruce.lucas&quot;&gt;bruce.lucas&lt;/a&gt;: I noticed that this P2 ticket got assigned on the Sharding backlog, but it is not clear to me what the expectation is for fixing it. The Global-X lock as part of these commit operations is not something new to 4.4 or 5.0, but it&apos;s been from the beginning of time. Removing &lt;tt&gt;applyOps&lt;/tt&gt; is a non trivial work, tracked under &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33326&quot; title=&quot;Remove use of applyOps/doTxn from sharding chunk operations&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33326&quot;&gt;&lt;del&gt;SERVER-33326&lt;/del&gt;&lt;/a&gt; and as of now is nowhere near being scheduled.&lt;/p&gt;

&lt;p&gt;Barring removing &lt;tt&gt;applyOps&lt;/tt&gt; what other options are there to fix the immediate FTDC problem?&lt;/p&gt;</comment>
                            <comment id="3912094" author="kaloian.manassiev" created="Thu, 1 Jul 2021 13:49:59 +0000"  >&lt;p&gt;The &lt;tt&gt;_configsvrCommitChunkSplit&lt;/tt&gt; command eventually calls &lt;tt&gt;applyOps&lt;/tt&gt; and this will take global X-lock unfortunately. All three of CommitChunkSplit/Merge/Move do that and we have ticket to rewrite them as transactions, but haven&apos;t gotten to that yet.&lt;/p&gt;

&lt;p&gt;I didn&apos;t read the rest of the comments so please let me know if there is something else I need to answer.&lt;/p&gt;</comment>
                            <comment id="3909841" author="louis.williams" created="Wed, 30 Jun 2021 13:45:28 +0000"  >&lt;p&gt;I can&apos;t tell from the code where&#160;_configsvrCommitChunkSplit is actually taking a global X lock. I&apos;m skeptical that it actually needs to because few things do.&#160;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kaloian.manassiev&quot; class=&quot;user-hover&quot; rel=&quot;kaloian.manassiev&quot;&gt;kaloian.manassiev&lt;/a&gt;, do you know why this operation is taking a global X lock?&lt;/p&gt;</comment>
                            <comment id="3909561" author="bruce.lucas@10gen.com" created="Wed, 30 Jun 2021 10:58:04 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt;, do you have an opinion on whether&#160;_configsvrCommitChunkSplit should be taking a global X lock?&lt;/p&gt;

&lt;p&gt;In any case I&apos;ll pass the ticket to the sharding team for their comment.&lt;/p&gt;</comment>
                            <comment id="3908979" author="louis.williams" created="Tue, 29 Jun 2021 22:10:00 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=bruce.lucas&quot; class=&quot;user-hover&quot; rel=&quot;bruce.lucas&quot;&gt;bruce.lucas&lt;/a&gt;, I think the problem is that applyOps uses too big of a hammer with its global exclusive lock. Nowadays, we only use the global lock to make operations conflict with the storage engine shutting down. And since FTDC collects statistics from the storage engine, it needs to ensure it does not shut down while doing so.&lt;/p&gt;

&lt;p&gt;I wonder if we should instead focus on why we&apos;re using applyOps for what appear to be routine operations on the config server? Or at least stop using a version of applyOps that has to take a global exclusive lock? From what I can tell, the problem is the use of the &quot;precondition&quot; in the command. Without this (and assuming all operations are CRUD ops), the global lock does not need to be taken. What do you think?&lt;/p&gt;</comment>
                            <comment id="3908608" author="bruce.lucas@10gen.com" created="Tue, 29 Jun 2021 19:51:52 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt;&#160;I see your point. On closer inspection the case we saw was on a config server, and the culprits were applyOps and&#160;_configsvrCommitChunkSplit, both of which (according to the logs) take a global X lock. It appears this is taking several seconds to acquire, blocking FTDC for the duration. The net result is missing WT and some other sections for several seconds, and schema changes every few seconds which decreases compression and limits retention.&lt;/p&gt;

&lt;p&gt;It does appear that increasing the lock acquisition timeout isn&apos;t the answer, but I&apos;m not sure what is. Logically I think there should be no reason we can&apos;t collect wiredTiger metrics during applyOps and&#160;_configsvrCommitChunkSplit. Is the problem here that we&apos;re using too big a hammer (global lock) to keep FTDC from accessing the storage engine when that&apos;s not safe?&lt;/p&gt;</comment>
                            <comment id="3905227" author="louis.williams" created="Mon, 28 Jun 2021 15:50:13 +0000"  >&lt;p&gt;I&apos;m a little confused about how the linked tickets are causing frequent schema changes.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-48221&quot; title=&quot;Shut down ftdc after storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-48221&quot;&gt;&lt;del&gt;SERVER-48221&lt;/del&gt;&lt;/a&gt;, which was backported to 4.4, added a lock timeout to the lock acquisition for the &quot;wiredtiger&quot; section. Since FTDC skips ticket acquisition, the only locks taken are the Global lock and RSTL. Both locks are normally uncontended except during state transitions or when operations hold the Global lock exclusively. Those are rollback, shutdown, and some applyOps operations. In the uncontended path, lock acquisitions do not evaluate the lock deadline, so the short deadline has no effect unless there is a conflicting operation holding one of these locks. Because these conflicting operations usually take a long time, I&apos;m skeptical that raising the deadline will help very much. Additionally, &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-30888&quot; title=&quot;Have FTDC code paths obtain locks with a timeout.&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-30888&quot;&gt;&lt;del&gt;SERVER-30888&lt;/del&gt;&lt;/a&gt; was not backported to 4.4, so I don&apos;t believe that change is causing problems at the moment.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=bruce.lucas&quot; class=&quot;user-hover&quot; rel=&quot;bruce.lucas&quot;&gt;bruce.lucas&lt;/a&gt;, do we have any idea what is conflicting with FTDC collection that prevents it from failing to collect so often? And what do you think is an acceptable timeout so that FTDC does not block and it alos has a better chance of making progress in the event of a long-running blocking operation? 100ms?&lt;/p&gt;</comment>
                            <comment id="3894741" author="bruce.lucas@10gen.com" created="Wed, 23 Jun 2021 17:57:54 +0000"  >&lt;p&gt;I&apos;ve marked this as affecting 4.4.4 and requested backports, although I think that only applies to a subset of the issues reported above.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10420">
                    <name>Backports</name>
                                            <outwardlinks description="backported by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="2146760">SERVER-70031</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="1881742">SERVER-60168</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="497859">SERVER-33326</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="421828">SERVER-30888</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="1351584">SERVER-48221</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>22.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_12751" key="com.atlassian.jira.plugin.system.customfieldtypes:multiselect">
                        <customfieldname>Assigned Teams</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="25129"><![CDATA[Server Security]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12450" key="com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes">
                        <customfieldname>Backport Requested</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="21777"><![CDATA[v5.0]]></customfieldvalue>
    <customfieldvalue key="18953"><![CDATA[v4.4]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Thu, 24 Jun 2021 17:55:39 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        1 year, 10 weeks ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<a href='https://jira.mongodb.org/browse/SERVER-70031'>SERVER-70031</a>]]></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_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>PM-2763</customfieldvalue>
                        </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>dbeng-pm-bot</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            1 year, 10 weeks 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>backlog-server-security</customfieldvalue>
            <customfieldvalue>bruce.lucas@mongodb.com</customfieldvalue>
            <customfieldvalue>connie.chen@mongodb.com</customfieldvalue>
            <customfieldvalue>daniel.gottlieb@mongodb.com</customfieldvalue>
            <customfieldvalue>kaloian.manassiev@mongodb.com</customfieldvalue>
            <customfieldvalue>louis.williams@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzoaxb:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr25kf:</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>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="5231">Execution Team 2021-10-04</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

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

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