<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 02:59: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>[SERVER-2114] Don&apos;t use select timeouts for fast coarse timing</title>
                <link>https://jira.mongodb.org/browse/SERVER-2114</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;The mongod process causes wakeups 100 times per second as can be seen by calling strace on the process.  This is done by calling having a one hundredth of a second timeout on a select call on the listening socket. These wakeups increase power consumption and utilization on virtual machines.  It should be noted that this happens all the time even if there are no connections or any other activity happening. Powertop will consistently show mongod as a top offender.  An explanation on the mailing list was given:&lt;/p&gt;

&lt;p&gt;&amp;gt;  One main reason is we need a somewhat coarse timer that is as fast as possible.&lt;br/&gt;
&amp;gt; So we use this one loop for incrementing that counter.&lt;br/&gt;
&amp;gt; This is much faster than using any system call for getting wall time.&lt;/p&gt;

&lt;p&gt;Linux has has a system call for a number of years for getting a timer value - clock_gettime.  Except for ancient 32 bit hardware this call is implemented using the VDSO mechanism - a page the kernel maps into process memory.  clock_gettime is implemented without there being a system call at all!  Heck they even added &quot;a somewhat coarse timer that is as fast as possible&quot;!  &lt;a href=&quot;http://lwn.net/Articles/342018/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://lwn.net/Articles/342018/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;You should be able to replace the timeouts and variable they were updating with calls to clock_getttime.&lt;/p&gt;</description>
                <environment>64 bit Ubuntu 10.10</environment>
        <key id="13728">SERVER-2114</key>
            <summary>Don&apos;t use select timeouts for fast coarse timing</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="andrew.morrow@mongodb.com">Andrew Morrow</assignee>
                                    <reporter username="rogerbinns">Roger Binns</reporter>
                        <labels>
                            <label>polish</label>
                            <label>pull-request</label>
                    </labels>
                <created>Thu, 18 Nov 2010 06:00:47 +0000</created>
                <updated>Thu, 2 Aug 2018 22:12:03 +0000</updated>
                            <resolved>Wed, 22 Jun 2016 16:06:00 +0000</resolved>
                                                                    <component>Networking</component>
                                        <votes>36</votes>
                                    <watches>48</watches>
                                                                                                                <comments>
                            <comment id="1302904" author="acm" created="Wed, 22 Jun 2016 16:06:00 +0000"  >&lt;p&gt;Hi watchers of this ticket -&lt;/p&gt;

&lt;p&gt;I&apos;m closing this ticket as &apos;done&apos;. As of &lt;a href=&quot;https://github.com/mongodb/mongo/commit/710159c9602a6738e6455cfb26bc2d70a0454ae2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/710159c9602a6738e6455cfb26bc2d70a0454ae2&lt;/a&gt;, the select timeout in the Listener class is no longer used for fast coarse timing.&lt;/p&gt;

&lt;p&gt;The Listener does still have a select timeout, currently at 250ms. However, that select timeout is there not for timekeeping, but to work around the fact that closing a listening socket is not guaranteed to unblock select, which currently frustrates the shutdown logic for the Listener. We expect this to be a temporary situation, ultimately resulting in the listen path not having any timeout. This also represents an order of magnitude reduction in wakeups.&lt;/p&gt;

&lt;p&gt;Note that we have not yet implemented &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-21538&quot; title=&quot;Choose clock source for reading current time dynamically at startup&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-21538&quot;&gt;&lt;del&gt;SERVER-21538&lt;/del&gt;&lt;/a&gt;. Until we do so, the server will continue to wake up on a 10ms interval while sampling the clock from a background thread. Once we do implement &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-21538&quot; title=&quot;Choose clock source for reading current time dynamically at startup&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-21538&quot;&gt;&lt;del&gt;SERVER-21538&lt;/del&gt;&lt;/a&gt;, the server will only sample on a 10ms schedule if the system clock is found to be expensive to read. Otherwise, if the system clock is cheap to read, the server will not consume power when idle just to implement time keeping. There may of course be other periodic wake-ups in the server, but probably none as aggressive as had been present for timekeeping.&lt;/p&gt;

&lt;p&gt;If the primary reason for following this ticket was interest in reduced power/battery consumption in mongod or mongos, please add yourself as a watcher on &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-21538&quot; title=&quot;Choose clock source for reading current time dynamically at startup&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-21538&quot;&gt;&lt;del&gt;SERVER-21538&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Also note that the patches posted here are unlikely to apply correctly after the recent changes to the listener.&lt;/p&gt;</comment>
                            <comment id="940389" author="schwerin" created="Mon, 15 Jun 2015 14:24:14 +0000"  >&lt;p&gt;I think the best way to move forward is to do a little more work abstracting the use of timers so that we can better select a time source based on the facilities available on the (virtual) hardware. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=renctan&quot; class=&quot;user-hover&quot; rel=&quot;renctan&quot;&gt;renctan&lt;/a&gt; recently introduced a TickSource interface to be used for doing elapsed time measurement (rather than reading the calendar time). If we got consistent about using that for elapsed time measurement, we could choose an implementation at start-up, and hang it off the ServiceContext. The question I&apos;ve still got to answer is whether we need a slow-but-precise timer on systems where the fastest clock device isn&apos;t very precise. I suspect the answer is usually &quot;no&quot;.  That we rarely, if ever, need a precise measurement of time if the cost of that measurement is more than a few microseconds.&lt;/p&gt;

&lt;p&gt;I&apos;m hoping to spend a little time thinking about this later in the summer, but my plate is pretty full right now. I know that &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=acm&quot; class=&quot;user-hover&quot; rel=&quot;acm&quot;&gt;acm&lt;/a&gt; wants to kill the elapsed time tracker, too, because it&apos;s an extra job for the networking code that he&apos;d rather it not have.&lt;/p&gt;</comment>
                            <comment id="938386" author="chengas123" created="Thu, 11 Jun 2015 22:20:20 +0000"  >&lt;p&gt;The issue that&apos;s been holding up &lt;a href=&quot;https://github.com/mongodb/mongo/pull/416&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;the PR&lt;/a&gt; is that Mongo is still supporting RHEL 5 and its 2.6.18 kernel, but CLOCK_MONOTONIC_COARSE wasn&apos;t introduced until 2.6.32. Mongo is planning to continue support for RHEL 5 in at least the next major release series - 3.2, so that&apos;s not likely to change soon.&lt;/p&gt;

&lt;p&gt;Any thoughts on moving forward? Should we work the current way for RHEL 5 and the new way for everyone else or would that be too messy?&lt;/p&gt;</comment>
                            <comment id="824227" author="mdcallag" created="Sat, 7 Feb 2015 19:26:16 +0000"  >&lt;p&gt;A random anecdote, but in the past mongod has been the largest CPU consumer on my Ubunutu VM when some  random binary depended on it but it wasn&apos;t doing anything.&lt;/p&gt;</comment>
                            <comment id="823443" author="greg_white" created="Fri, 6 Feb 2015 16:50:42 +0000"  >&lt;p&gt;That&apos;s a shame, because it make using mongo as part of a dev stack on a notebook particularly painful.  On my laptop, it&apos;s the single largest power draw, even when idle.&lt;/p&gt;</comment>
                            <comment id="823425" author="acm" created="Fri, 6 Feb 2015 16:38:45 +0000"  >&lt;p&gt;Hi All -&lt;/p&gt;

&lt;p&gt;I know there is a lot of interest in this ticket. We are holding off on changes in this area because we are currently evaluating the overall server network stack with an eye towards a significant refactoring or rewrite, much as has happened with other critical server subsystems during the 2.4, 2.6, and 3.0 release cycles. It is our expectation that the issue identified in this ticket would likely be tackled as part of such a refactoring, currently planned for the upcoming development cycle.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;br/&gt;
Andrew&lt;/p&gt;</comment>
                            <comment id="815273" author="greg_white" created="Wed, 28 Jan 2015 12:58:53 +0000"  >&lt;p&gt;3.0.0-rc6 has a serious regression in power usage.  It&apos;s now using ~4x the power the 2.8-rc5 used - wakeups went from ~60 a second to to &amp;gt; 210 wakeups/sec.&lt;/p&gt;

&lt;p&gt;Edit: That&apos;s using WiredTiger.  Using the mmap storage engine, things are between 2-3x worse at ~140 wakeups/sec.&lt;/p&gt;
</comment>
                            <comment id="633445" author="vladz-hola" created="Wed, 25 Jun 2014 07:17:18 +0000"  >&lt;p&gt;Applying the mongo-timer-fix patch with the patches from &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-9580&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SERVER-9580&lt;/a&gt; has helped us reduce CPU usage on development machines. We have packaged the patches for Ubuntu at &lt;a href=&quot;https://build.opensuse.org/package/show/home:dottedmag:mongodb/mongodb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://build.opensuse.org/package/show/home:dottedmag:mongodb/mongodb&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="506573" author="chengas123" created="Thu, 27 Feb 2014 19:08:10 +0000"  >&lt;p&gt;I&apos;ve run into this being a problem as well. It would be really great to get this patch reviewed. It&apos;s a pretty small limited change.&lt;/p&gt;</comment>
                            <comment id="505564" author="lindem" created="Wed, 26 Feb 2014 11:41:10 +0000"  >&lt;p&gt;I have been using Calvin&apos;s Patch since 2.4.6. My scenario is that I am a developer running mongodb on my work laptop. &lt;/p&gt;

&lt;p&gt;(I asked Calvin for an update to the patch since it failed to apply in git master.)&lt;/p&gt;

&lt;p&gt;The patch makes wakeups go from 200 per second to 20 per second for MongoDB, measured with powertop, and that is &lt;b&gt;idle&lt;/b&gt; mongodb, just started up for like ten minutes, no ops at all, with version 2.4.6. &lt;/p&gt;

&lt;p&gt;I realize my use case of mongodb eating my battery is perhaps only of minor importance to the grand scheme of things, but I humbly ask for another consideration to please include this patch. Maybe it&apos;d be possible to make a compiler option out of it? &lt;/p&gt;

&lt;p&gt;What exactly is holding the bug up and unresolved for that long of a time?&lt;/p&gt;

&lt;p&gt;Thanks for consideration.&lt;/p&gt;</comment>
                            <comment id="505201" author="axkibe" created="Tue, 25 Feb 2014 20:58:41 +0000"  >&lt;p&gt;Yay! hope it gets in there. &lt;b&gt;fingers crossed&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Just measured it on my notebook estimated battery runtime. its 5% longer without mongodb running - with no connected clients.&lt;/p&gt;

&lt;p&gt;Otherwise is there a fool proof way to replace the mongod that came with debian (jessie here) by one compiled with your patch?&lt;/p&gt;
</comment>
                            <comment id="505116" author="jcalvinowens" created="Tue, 25 Feb 2014 19:49:20 +0000"  >&lt;p&gt;Updating the patch to apply to the current git HEAD - I&apos;ve heard from a couple developers who say they use it.&lt;/p&gt;</comment>
                            <comment id="325471" author="rogerbinns" created="Wed, 1 May 2013 06:28:37 +0000"  >&lt;p&gt;Note that your estimate is only taking into account when MongoDB is running on bare metal.  When running virtualized/hypervisor then the host also has to dedicate cycles to this timer and wakeups and those cycles can&apos;t be used for useful work either.&lt;/p&gt;</comment>
                            <comment id="323611" author="jcalvinowens" created="Sun, 28 Apr 2013 20:09:36 +0000"  >&lt;p&gt;Update: &lt;a href=&quot;https://http.snarkywidgets.com/mongo-timer-fix-v3.patch&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://http.snarkywidgets.com/mongo-timer-fix-v3.patch&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="318209" author="jcalvinowens" created="Sun, 21 Apr 2013 20:36:25 +0000"  >&lt;p&gt;Also, some crude estimation using my desktop predicts that this fix would save you about 36.5 KWh/year per server, or about $5 at the average US price. In a large datacenter, that could be quite significant. YMMV.&lt;/p&gt;</comment>
                            <comment id="318207" author="jcalvinowens" created="Sun, 21 Apr 2013 20:33:12 +0000"  >&lt;p&gt;I&apos;ve cooked up a fix for this, tested on Linux. Unfortunately, I don&apos;t have access to an OSX, Windows, or Solaris machine I can test this on. Can anybody here test on any of those platforms?&lt;/p&gt;

&lt;p&gt;Patch (against current master): &lt;a href=&quot;https://http.snarkywidgets.com/mongo-timer-fix-v1.patch&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://http.snarkywidgets.com/mongo-timer-fix-v1.patch&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Remaining questions:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;The performance hit on Linux is negligible - is that the case on other platforms? Linux is the biggest use case, so if not, do we care?&lt;/li&gt;
	&lt;li&gt;Is it necessary to handle overflow? A signed 64-bit integer will overflow at 300 million years counting milliseconds, but my understanding is that (at least on Linux) there is no guarantee that the counter will start at zero. Thoughts?&lt;/li&gt;
	&lt;li&gt;The counter is signed on every platform but OSX, where it is unsigned. But since on OSX it is directly tied to CPU cycles (and therefore starts from zero), I don&apos;t see how it could ever be large enough to matter - even if it counts clock cycles, on a 10GHz machine it would take 30 years to get there. Am I missing something?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I&apos;m going to wait to submit a pull request until testing has been done on at least OSX and Windows.&lt;/p&gt;

&lt;p&gt;(NOTE: I did try to test this on my iMac, but the build has been broken on 32-bit OSX for a long time, apparently)&lt;/p&gt;</comment>
                            <comment id="227072" author="rogerbinns" created="Sun, 30 Dec 2012 05:22:34 +0000"  >&lt;p&gt;There is no debate over whether this can be fixed technically and how to fix it.  Commenters and voters believe it should be fixed.  10gen has chosen not to work on it yet.&lt;/p&gt;

&lt;p&gt;If you fix it then that would be great!&lt;/p&gt;</comment>
                            <comment id="227069" author="jcalvinowens" created="Sun, 30 Dec 2012 05:17:20 +0000"  >&lt;p&gt;That&apos;s my point - why not use clock_gettime() or one of his friends? It was alluded to in the original post that an efficient alternative to repeatedly calling select() didn&apos;t exist.&lt;/p&gt;

&lt;p&gt;getElapsedTimeMillis() could just call clock_gettime(CLOCK_MONOTONIC_RAW), which would perpetuate tiny latency increases, but would allow select() to block forever waiting for connections - a big win in terms of power consumption and CPU usage. As a bonus, you&apos;d get a more accurate timer, since it would have nanosecond precision and wouldn&apos;t drift on the long side, as one based on select() will do over time.&lt;/p&gt;

&lt;p&gt;Here&apos;s a benchmark of alternative timer methods: &lt;a href=&quot;http://stackoverflow.com/questions/6498972/faster-equivalent-of-gettimeofday/13096917#13096917&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://stackoverflow.com/questions/6498972/faster-equivalent-of-gettimeofday/13096917#13096917&lt;/a&gt;&lt;br/&gt;
Obviously that&apos;s oversimplified, but it gives you an idea that these calls really aren&apos;t expensive.&lt;/p&gt;</comment>
                            <comment id="227057" author="rogerbinns" created="Sun, 30 Dec 2012 04:47:45 +0000"  >&lt;p&gt;Each timer call is not inefficient by itself.  The problem is the quantity of them - 200 per second even if not a single client is connected.  This causes greatly increased power consumption - &lt;a href=&quot;https://lesswatts.org/documentation/silicon-power-mgmnt/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://lesswatts.org/documentation/silicon-power-mgmnt/&lt;/a&gt; and for virtualized environments means that the host also has to do work.  In addition (on Linux) there is no need to run such a frequent timer since clock_gettime() can be used get a timer value on demand.&lt;/p&gt;

&lt;p&gt;Run powertop to see just how bad mongodb is.  And idle instance should have zero wakeups per second while a connected instance should have wakeups proportional to the amount of connection traffic.&lt;/p&gt;</comment>
                            <comment id="227039" author="jcalvinowens" created="Sun, 30 Dec 2012 04:02:45 +0000"  >&lt;p&gt;I would like to fix this. Could somebody clarify for me:&lt;br/&gt;
        1) Why are the timer system calls are believed to be inefficient?&lt;br/&gt;
        2) The loop checks the return of inShutdown() to end its thread. Why can&apos;t this be done via a signal? Even if the fundamental exit path isn&apos;t easy to change, the dbExit function can simply raise SIGUSR1 or suchlike, for which we can set a handler to do nothing, to make select() return and check inShutdown() again.&lt;/p&gt;

&lt;p&gt;Thoughts?&lt;/p&gt;</comment>
                            <comment id="219115" author="hrj" created="Wed, 19 Dec 2012 10:14:34 +0000"  >&lt;p&gt;My virtual machine is waking up 400 times/second. Inside the virtual machine, mongodb is waking up 200 times/second.&lt;/p&gt;

&lt;p&gt;Please solve this for the love of our environment.&lt;/p&gt;</comment>
                            <comment id="172487" author="erundook" created="Mon, 8 Oct 2012 09:57:50 +0000"  >&lt;p&gt;+1 for this bug. affects both my macbook and linode VM. it has been there for two years! just wondering...&lt;/p&gt;</comment>
                            <comment id="140643" author="axkibe" created="Sun, 8 Jul 2012 06:46:40 +0000"  >&lt;p&gt;If this could be fixed! clock() returning the kernel jiffies sure isn&apos;t slower than doing a timeout every 10ms. Or just increase the timeouts and add the timer counter by larger values (even calculated)&lt;/p&gt;

&lt;p&gt;On my Macbook air, mongodb is always a top CPU users and moves it to fan usage.&lt;/p&gt;

&lt;p&gt;That mongodb is an all powerfull database is cool, but it would be even cooler if it would be scaleable as well, meaning to be able to scale down and be a not unnecessary powerdrain on mobile devices, when nothing is going on.&lt;/p&gt;</comment>
                            <comment id="133806" author="mulleteer" created="Mon, 18 Jun 2012 03:42:21 +0000"  >&lt;p&gt;This issue makes laptop development use with MongoDB bit harder. Mongod takes constantly few % of cpu and causes increased battery drainage. &lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="77169">SERVER-9818</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="63669">SERVER-8381</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="278329">SERVER-23614</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="60569">SERVER-8049</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="273739">SERVER-23243</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="240102">SERVER-21538</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="12223">SERVER-1279</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="160100">SERVER-15389</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="68048">SERVER-8939</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="26165" name="mongo-timer-fix-v1.patch" size="6446" author="jcalvinowens" created="Sun, 21 Apr 2013 20:33:28 +0000"/>
                            <attachment id="26407" name="mongo-timer-fix-v3.patch" size="6281" author="jcalvinowens" created="Sun, 28 Apr 2013 20:09:56 +0000"/>
                            <attachment id="38385" name="mongo-timer-fix-v4.patch" size="6880" author="jcalvinowens" created="Tue, 25 Feb 2014 19:49:20 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>24.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_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Mon, 18 Jun 2012 03:42:21 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        7 years, 34 weeks ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></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-314</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>oleg.pudeyev@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            7 years, 34 weeks ago
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_16465" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Linked BF Score</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Old_Backport</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10000"><![CDATA[No]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10020"><![CDATA[Linux]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>andrew.morrow@mongodb.com</customfieldvalue>
            <customfieldvalue>schwerin@mongodb.com</customfieldvalue>
            <customfieldvalue>axkibe</customfieldvalue>
            <customfieldvalue>chengas123</customfieldvalue>
            <customfieldvalue>jcalvinowens</customfieldvalue>
            <customfieldvalue>greg_white</customfieldvalue>
            <customfieldvalue>hrj</customfieldvalue>
            <customfieldvalue>mdcallag</customfieldvalue>
            <customfieldvalue>rogerbinns</customfieldvalue>
            <customfieldvalue>mulleteer</customfieldvalue>
            <customfieldvalue>lindem</customfieldvalue>
            <customfieldvalue>erundook</customfieldvalue>
            <customfieldvalue>vladz-hola</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrpb8f:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hsmbg7:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>20538</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="1064">Platforms 16 (06/24/16)</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </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|hriwu7:</customfieldvalue>

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