<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:53:02 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[JAVA-774] Add support for asynchronous operations</title>
                <link>https://jira.mongodb.org/browse/JAVA-774</link>
                <project id="10006" key="JAVA">Java Driver</project>
                    <description>&lt;p&gt;It would be great to have the Java driver be non-blocking. As far as I know it&apos;s currently only possible to make non-blocking requests if I use the Scala ReactiveMongo driver&lt;/p&gt;</description>
                <environment></environment>
        <key id="66760">JAVA-774</key>
            <summary>Add support for asynchronous operations</summary>
                <type id="11" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14707&amp;avatarType=issuetype">Epic</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="-1">Unassigned</assignee>
                                    <reporter username="chengas123">Ben McCann</reporter>
                        <labels>
                    </labels>
                <created>Thu, 28 Feb 2013 07:41:45 +0000</created>
                <updated>Tue, 31 May 2016 17:53:02 +0000</updated>
                            <resolved>Tue, 31 Mar 2015 17:45:42 +0000</resolved>
                                                    <fixVersion>3.0.0</fixVersion>
                                    <component>Async</component>
                                        <votes>10</votes>
                                    <watches>19</watches>
                                                                                                                <comments>
                            <comment id="521548" author="jeff.yemin" created="Mon, 24 Mar 2014 13:21:12 +0000"  >&lt;p&gt;One other point I should have made in my last comment: Both the AIO and the Netty support are just implementations of the &lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/connection/Stream.java#L29&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/connection/Stream.java#L29&lt;/a&gt; interface defined by the driver, and so it would be fairly straightforward to create another implementation on top of a different library (e.g. Unix domain sockets) and plug it in to your application.&lt;/p&gt;</comment>
                            <comment id="521541" author="remonvv" created="Mon, 24 Mar 2014 13:15:24 +0000"  >&lt;p&gt;I&apos;d say point 2) hints at the most important advantage. AIO is a very low-level API and Netty includes various solutions to non-trivial problems that would otherwise would have to be implemented in the MongoDB driver from scratch. Add to that that Netty is probably the most widely used and thus most proven library for this sort of thing (as opposed to MINA, Grizzly, etc.) it&apos;s a low risk dependency. &lt;/p&gt;</comment>
                            <comment id="521031" author="jeff.yemin" created="Fri, 21 Mar 2014 21:03:29 +0000"  >&lt;p&gt;Hi Nils,&lt;/p&gt;

&lt;p&gt;Thanks for your interest in async.  &lt;/p&gt;

&lt;p&gt;We are still leveraging AIO and have no plans currently to remove &lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/connection/AsynchronousSocketChannelStream.java&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;AsynchronousSocketChannelStream&lt;/a&gt;.  This is the default implementation that the driver uses for async.&lt;br/&gt;
Furthermore, there is not a hard dependency on Netty.  It&apos;s opt-in (via a system property, though that may change), and if you don&apos;t opt-in, Netty does not need to be on the classpath.&lt;/p&gt;

&lt;p&gt;But Netty gives us some advantages.&lt;/p&gt;

&lt;p&gt;1. AsynchronousSocketChannel was introduced in Java 7, and we would like a solution for our Java 6 users.  Netty is supported on Java 6 and up.&lt;br/&gt;
2. Our AsynchronousSocketChannel-based implementation does not support SSL, and adding that support is non-trivial.  With Netty, it&apos;s just a few lines of code.&lt;br/&gt;
3. For applications that already use Netty for the rest of their I/O needs, a Netty-based driver for MongoDB may integrate better.  For example, they could share an instance of an &lt;a href=&quot;http://netty.io/4.0/api/io/netty/channel/nio/NioEventLoopGroup.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;NioEventLoopGroup&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;That said, if you have specific objections to any reliance on Netty we would definitely like to hear them.&lt;/p&gt;

&lt;p&gt;Regards,&lt;br/&gt;
Jeff&lt;/p&gt;</comment>
                            <comment id="520675" author="nilskp" created="Fri, 21 Mar 2014 13:47:02 +0000"  >&lt;p&gt;What was the reason to add the Netty dependency rather than leverage Java AIO?&lt;/p&gt;</comment>
                            <comment id="520549" author="jeff.yemin" created="Fri, 21 Mar 2014 01:55:12 +0000"  >&lt;p&gt;For anyone interested, I have a working branch of 3.0.x that works with Netty 4.0: &lt;a href=&quot;https://github.com/jyemin/mongo-java-driver/tree/3.0.x-netty&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/jyemin/mongo-java-driver/tree/3.0.x-netty&lt;/a&gt;.  &lt;/p&gt;

&lt;p&gt;Feedback is appreciated.&lt;/p&gt;</comment>
                            <comment id="387876" author="nilskp" created="Wed, 24 Jul 2013 15:58:40 +0000"  >&lt;p&gt;Well, maybe 2, one for reads the other for writes. It&apos;s been a while since I&apos;ve done non-blocking I/O using selectors, and it was only for one-way traffic, so I&apos;m a little rusty.&lt;/p&gt;</comment>
                            <comment id="387867" author="remonvv" created="Wed, 24 Jul 2013 15:48:17 +0000"  >&lt;p&gt;Nils, so a thread per connection strategy? Provided the amount of connections is relatively limited that should be okay.&lt;/p&gt;</comment>
                            <comment id="387861" author="nilskp" created="Wed, 24 Jul 2013 15:39:59 +0000"  >&lt;p&gt;EDIT: What I&apos;m trying to say is, that I would expect each connection to have a single selector, thus be single-threaded. And you should then be able to control the connection pool size, so that each connection == single thread == single selector.&lt;/p&gt;

&lt;p&gt;Sorry for any confusion.&lt;/p&gt;</comment>
                            <comment id="387857" author="nilskp" created="Wed, 24 Jul 2013 15:37:22 +0000"  >&lt;p&gt;Remon, I think this comes down to whether you value latency or throughput.&lt;/p&gt;

&lt;p&gt;I certainly hope there will be an option to limit both physical I/O connections and the number of selector threads.&lt;/p&gt;</comment>
                            <comment id="387806" author="remonvv" created="Wed, 24 Jul 2013 14:38:43 +0000"  >&lt;p&gt;Nils, there&apos;s a number of reasons why that isn&apos;t optimal (or even possible). A single thread would mean only a single physical core can process MongoDB traffic, only a single operation can execute concurrently and so I don&apos;t think that&apos;s an option. In a non-blocking framework the multiple threads wouldn&apos;t be really be contending for the same I/O resources anyway as each worker thread would be assigned it&apos;s own I/O resource (connection) to perform an A/C/R/W on. &lt;/p&gt;

&lt;p&gt;Generally speaking a single thread implementation (server and client) rarely reach maximum throughput. It&apos;s roughly for that reason why things like node.js and Redis require multiple instances on the same physical machine to maximimze throughput. That said, there is value in having as few threads as possible. If the entire driver is mostly non-blocking this max should be roughly the amount of physical/virtual processing units.&lt;/p&gt;

&lt;p&gt;A single connection introduces some of the same limitations.&lt;/p&gt;
</comment>
                            <comment id="387804" author="remonvv" created="Wed, 24 Jul 2013 14:36:44 +0000"  >&lt;p&gt;Justin, sounds like a good plan &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/wink.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;</comment>
                            <comment id="387772" author="justin.lee@10gen.com" created="Wed, 24 Jul 2013 13:39:36 +0000"  >&lt;p&gt;Remon, we&apos;re hoping/planning to remove that dependency.&lt;/p&gt;</comment>
                            <comment id="387753" author="nilskp" created="Wed, 24 Jul 2013 13:16:15 +0000"  >&lt;p&gt;Jeff, you mention that &quot;we also need a non-blocking connection pool&quot;, but why is that? Why not use a single connection and single thread? Since it&apos;s async this should work very well, probably even better than multiple thread contending over I/O resources, and it&apos;s more efficient for the server too.&lt;/p&gt;</comment>
                            <comment id="387665" author="remonvv" created="Wed, 24 Jul 2013 09:59:53 +0000"  >&lt;p&gt;Out of pure curiousity, what&apos;s the rationale behind making 3.x drivers Java 7+? NIO is only a slightly more verbose/low-level API than ASC is and Java 7 adaption isn&apos;t exactly great still.&lt;/p&gt;</comment>
                            <comment id="340954" author="jeff.yemin" created="Tue, 21 May 2013 20:28:55 +0000"  >&lt;p&gt;Fall 2013.  You can track in on the Jira roadmap.&lt;/p&gt;</comment>
                            <comment id="340952" author="nilskp" created="Tue, 21 May 2013 20:24:32 +0000"  >&lt;p&gt;Jeff, asynchronoussocketchannel sounds like a good choice. Is there an approximate ETA on the 3.0 driver?&lt;/p&gt;</comment>
                            <comment id="340915" author="chengas123" created="Tue, 21 May 2013 19:24:03 +0000"  >&lt;p&gt;Right, I know. Totally worth it though&lt;/p&gt;</comment>
                            <comment id="340912" author="jeff.yemin" created="Tue, 21 May 2013 19:19:43 +0000"  >&lt;p&gt;You&apos;ll have the same problem with MongoJack though, as it also will need an async API makeover.&lt;/p&gt;</comment>
                            <comment id="340890" author="chengas123" created="Tue, 21 May 2013 18:45:49 +0000"  >&lt;p&gt;No problem. I&apos;m happy to port as needed. I gave up on using Morphia anyway. It was way too buggy and unmaintained and had a horrible memory leak that causing us lots of headaches. I&apos;m much happier using MongoJack now.&lt;/p&gt;</comment>
                            <comment id="340831" author="jeff.yemin" created="Tue, 21 May 2013 17:46:39 +0000"  >&lt;p&gt;Oops, I had already mentioned that!&lt;/p&gt;</comment>
                            <comment id="340829" author="jeff.yemin" created="Tue, 21 May 2013 17:46:12 +0000"  >&lt;p&gt;Ben, there&apos;s no way that the existing Morphia API will become asynchronous without a bit of work, but we will likely have a way that you&apos;ll be able to use your existing @Entity-annotated classes directly with the driver&apos;s async API.&lt;/p&gt;</comment>
                            <comment id="340820" author="chengas123" created="Tue, 21 May 2013 17:35:34 +0000"  >&lt;p&gt;+1 for AsynchronousSocketChannel. sounds like absolutely the right way to go&lt;/p&gt;</comment>
                            <comment id="340811" author="jeff.yemin" created="Tue, 21 May 2013 17:25:05 +0000"  >&lt;p&gt;Nils, our current prototype of this feature uses AsynchronousSocketChannel (and hence depends on Java 7).  That is most likely going to remain, though we haven&apos;t made a final decision.&lt;/p&gt;

&lt;p&gt;Also, it&apos;s a bit more complicated than that, because we also need a non-blocking connection pool. &lt;/p&gt;</comment>
                            <comment id="340565" author="nilskp" created="Tue, 21 May 2013 13:48:48 +0000"  >&lt;p&gt;I am going to assume, and want to make sure, that the non-blocking behavior will be implemented using NIO selectors, correct?&lt;/p&gt;</comment>
                            <comment id="278382" author="chengas123" created="Thu, 28 Feb 2013 19:17:00 +0000"  >&lt;p&gt;Ok, sounds good. I don&apos;t have any problem switching my annotations to use the javax.persistence annotations or something else if needed. It&apos;s a very easy search and replace. One there&apos;s some sort of serializer for Java objects (doesn&apos;t have to be Morphia), I&apos;d be happy to test it out.&lt;/p&gt;</comment>
                            <comment id="278379" author="jeff.yemin" created="Thu, 28 Feb 2013 19:14:08 +0000"  >&lt;p&gt;Morphia is not going to be rolled in, but we are going to write a Morphia serializer that will allow you to use classes with Morphia annotations directly with the new API, including the async API.  But that piece is not done yet.&lt;/p&gt;</comment>
                            <comment id="278263" author="chengas123" created="Thu, 28 Feb 2013 16:56:30 +0000"  >&lt;p&gt;Btw, if there&apos;s some ORM functionality built-in (e.g. Morphia rolled in) then I&apos;d be happy to plop it into my app and test it. Otherwise it might be pretty tough for me to test in my existing app since I don&apos;t use the driver directly.&lt;/p&gt;</comment>
                            <comment id="278258" author="chengas123" created="Thu, 28 Feb 2013 16:53:16 +0000"  >&lt;p&gt;Awesome! I&apos;m super excited for the v3 driver now!&lt;/p&gt;</comment>
                            <comment id="278022" author="jeff.yemin" created="Thu, 28 Feb 2013 12:39:51 +0000"  >&lt;p&gt;I agree, and we&apos;re working on it.  If you&apos;d like to test out what we have so far, please let me know.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                                        </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10858" key="com.pyxis.greenhopper.jira:gh-epic-label">
                        <customfieldname>Epic Name</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Async</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10859" key="com.pyxis.greenhopper.jira:gh-epic-status">
                        <customfieldname>Epic Status</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10642"><![CDATA[Done]]></customfieldvalue>

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

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