Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1474236000 [2017/05/27 13:44]
irc:1474236000 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:11:18] <​non-blocking>​ maybe @temporalfox knows the answer
 +
 +[00:11:24] <​temporalfox>​ hi
 +
 +[00:11:37] <​non-blocking>​ I'm using mongodb async driver ? do you guys see any problem using it ? I mean, mongo driver async will create his own event loop.
 +
 +[00:11:42] <​temporalfox>​ vertx provides a mongodb async driver
 +
 +[00:11:43] <​non-blocking>​ what kind of problems would happen ?
 +
 +[00:11:47] <​temporalfox>​ I mean an integration for
 +
 +[00:11:56] <​non-blocking>​ one '​issue'​ could be a race condition on closure variables . I mean, two threads modifying variables ( vertx eventloop and mongo async driver event loop ). am I correct ?
 +
 +[00:12:01] <​temporalfox>​ http://​vertx.io/​docs/​vertx-mongo-client/​java/​
 +
 +[00:12:13] <​non-blocking>​ just saw the vertx mongo, but missing some methods
 +
 +[00:12:17] <​non-blocking>​ for instance, findAndModify
 +
 +[00:12:27] <​non-blocking>​ and aggregations
 +
 +[00:12:51] <​non-blocking>​ so, my question is, what kind of problem would happen using mongo async driver
 +
 +[00:12:51] <​non-blocking>​ ?
 +
 +[00:13:32] <​temporalfox>​ I don't know precisely
 +
 +[00:13:42] <​temporalfox>​ I don't know how this driver works
 +
 +[00:13:51] <​temporalfox>​ i.e which thread make the callback
 +
 +[00:14:02] <​temporalfox>​ I think the best is to look at the mongo client
 +
 +[00:14:07] <​temporalfox>​ and see how it does
 +
 +[00:14:12] <​temporalfox>​ and do the same manually
 +
 +[00:14:34] <​non-blocking>​ for instance, the async driver uses nio/netty
 +
 +[00:14:59] <​non-blocking>​ it spanw his own event loop
 +
 +[00:16:02] <​temporalfox>​ I see
 +
 +[00:16:24] <​temporalfox>​ so I htink the callback should be done on the current vertx thread
 +
 +[00:16:32] <​temporalfox>​ it would be great if the same thread could be used though
 +
 +[00:16:42] <​non-blocking>​ the computation,​ right ?
 +
 +[00:16:43] <​temporalfox>​ i.e force mongo to reuse vertx thread
 +
 +[00:16:51] <​temporalfox>​ as both are netty threads
 +
 +[00:16:55] <​temporalfox>​ and the same tech
 +
 +[00:17:01] <​non-blocking>​ what kind of problem you see without using the verx thread ?
 +
 +[00:17:04] <​temporalfox>​ it's actually an ithread
 +
 +[00:17:19] <​temporalfox>​ memory visibility issue
 +
 +[00:17:30] <​temporalfox>​ if you are inside a verticle and access verticle state
 +
 +[00:17:45] <​non-blocking>​ gotcha
 +
 +[00:18:05] <​non-blocking>​ I could see a stale value
 +
 +[00:18:14] <​temporalfox>​ I'm wondering if the same thread could be used
 +
 +[00:20:03] <​non-blocking>​ yeah, really don't know
 +
 +[00:20:21] <​non-blocking>​ if it possible, how could I pass the vertx event loop to mongo
 +
 +[00:21:20] <​temporalfox>​ by using the vertx COntext object
 +
 +[00:21:27] <​temporalfox>​ which provides the netty event loop of this context
 +
 +[00:21:51] <​non-blocking>​ can I see any example of this ?
 +
 +[00:21:57] <​non-blocking>​ would help a lot
 +
 +[00:22:55] <​temporalfox>​ https://​github.com/​vietj/​vertx-materials/​blob/​master/​src/​main/​asciidoc/​output/​book.adoc
 +
 +[00:23:01] <​temporalfox>​ integrating netty chapter
 +
 +[00:23:14] <​temporalfox>​ context.nettyEventLoop();​
 +
 +[00:23:26] <​non-blocking>​ thank you for your time
 +
 +[00:23:29] <​non-blocking>​ and patience !
 +
 +[00:23:49] <​temporalfox>​ you're welcome
 +
 +[08:42:01] *** ChanServ sets mode: +o temporalfox