Java Async Client

[Jeremy Truelove]

Does the mongo java driver support async, for use in frameworks like netty. What I'm specifically looking for are non-blocking reads and writes where the results are passed back via a callback and don't block the calling thread at all besides hand off.

jt

[Rob Moore]

The current released driver from MongoDB Inc. does not support asynchronous requests. The 3.0 release will have some async support based on Netty.

The Asynchronous Java driver (http://www.allanbank.com/mongodb-async-driver/) does support asynchronous requests (in addition to a synchronous requests based on the the asynchronous core). The driver uses distinct threads to do the I/O per socket and you can choose if the application thread does the send (default ConnectionModel) or if it hands off to a send thread.

We have a working prototype/hack of the driver using the Netty framework but it is not ready for the light of day as we are rapidly changing interfaces etc. The next release's major feature will be support for "connection plugins" like Netty.

Rob.

[Sébastien Dionne]

You should contact Jean-Francois Arcand to show you how to integrate async with Atmosphere instead of developing your own bridge over Netty.   I worked on Atmosphere and it easy to integrate your application into Atmosphere framework.

his web sites are : http://async-io.org/  and https://github.com/Atmosphere/atmosphere


you can take a look at https://github.com/Atmosphere/wasync

wAsync is a Java based library allowing asynchronous communication with any WebServer supporting the WebSocket or Http Protocol. wAsync can be used with Node.js, Android, Atmosphere or any WebSocket Framework.

On Tuesday, September 16, 2014 2:11:37 PM UTC-4, Jeremy Truelove wrote:

[Nelson Pereira Junior]

Rob, you say that mongodb-async-driver use threads. It's bad, it's no correct NIO implementation. The connection with the mongodb should also be non-block. do not you think?

[Rob Moore]

On Sunday, October 12, 2014 5:37:47 PM UTC-4, Nelson Pereira Junior wrote:

Rob, you say that mongodb-async-driver use threads. It's bad, it's no correct NIO implementation. The connection with the mongodb should also be non-block. do not you think?

I never claimed that the current implementation was "NIO".  It is asynchronous and mostly non-blocking. NIO is not required to be asynchronous or non-blocking.

The driver was born out of a need to create an application that needed to extract every last bit of performance it could on both the application and MongoDB side. Our testing (and that of others you can find on the internet) was that BIO using a thread to read and a thread to write performs better than using NIO. It also has the advantage that the programing model is much easier to wrap your head around. Even in the NIO case you still need to determine the right thread model and allocation strategy (single thread, N threads, thread per N connections, etc) for you application.

A lot of people confuse the need for a server to _accept_ hundreds to thousands of mostly idle connections with the need for that same server to create a much smaller pool of connection to other resources. The driver is in that latter camp and needs to manage many fewer connections than a typical internet facing server will receive.

The other reason that people use NIO is for "non-blocking". This is a little bit of a double edged sword and having the driver just absorb all of the requests into an internal infinite buffer will eventually cause its own problems. This is generally referred to as the need for "back pressure". What we have done in the driver is give the ability to manage the amount of buffering the driver will do before applying back pressure (via blocking) threads making requests via the driver. The thing the driver won't do that may be useful is fail a request based on too many pending requests. That would not be hard to implement and if you are interested in that feature please add an issue here.

As I said in the previous post in this thread. There will be the ability to support Netty and other connection models in the next version of the driver. That will get rid of all but 1 of the driver's threads to monitor the cluster is it connected to. 

As we implement the Netty connection model we, as we always do, will try and get every last drop of performance from Netty but given our previous testing I do not expect it to perform as well as the two-thread connection model.

Rob.

[Nelson Pereira Junior]

Hi Rob, thank you for your excellent explanation.

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to a topic in the Google Groups "mongodb-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mongodb-user/ZQFEhkAqEmo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/e97a83eb-eb61-4f54-9107-c3e6e921bf0f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.