This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[14:47:15] * ChanServ sets mode: +o temporal_ [14:47:44] * ChanServ sets mode: +o temporalfox

[15:18:12] * ChanServ sets mode: +o temporalfox [17:11:52] <asynco> I'm doing a project using vert.x3 and mongodb ( java ). I'm using the mongodb async driver on my project. I was wondering how the mongo driver will attach to the event queue the events properly,I feel that using the mongoDB async driver, I'm doing the work outside the vertx eventloop. is any way to add that to the vertx eventloop ? Am I wrong about that ? [17:12:05] <asynco> i'm back again AlexLehm [17:12:16] <asynco> will be for a long time now [17:16:25] <temporalfox> asynco hi [17:16:31] <temporalfox> AlexLehm hi, please look at [17:16:53] <temporalfox> seems related to vertx google group discussion about IPV6 [17:17:08] <temporalfox> asynco if you use the vertx-mongo-client you will be on the right event loop [17:19:57] <asynco> hey Temporalfox, do you know how the vertx-mongo-client attach to the vertx event loop ? [17:20:16] <temporalfox> normally if you are running in a verticle it should work OOTB transparently for you [17:20:21] <asynco> because, mongoASync uses netty right ? and netty spawn his own event loop [17:20:36] <asynco> that is really interesting ! [17:20:58] <asynco> I wonder how the mongoAsync is aware that he is running inside vert.x [17:21:06] <asynco> that is super interesting actually [17:21:09] <temporalfox> for instance [17:21:10] <temporalfox> [17:21:16] <temporalfox> you can see [17:21:17] <temporalfox> context.runOnContext(v → { [17:21:24] <temporalfox> that will callback on the event loop [17:21:32] <temporalfox> obtained from Context context = vertx.getOrCreateContext(); [17:21:38] <asynco> context.runOnContext is the responsible [17:21:41] <temporalfox> before calling mongo and getting the callback from mongo [17:21:42] <temporalfox> yes [17:21:49] <asynco> amazing amazing temporalFox [17:22:16] <asynco> so it means that mongo async driver run using his own eventloop and send back to the vertx through context.runOnContext [17:22:23] <temporalfox> yes [17:22:30] <temporalfox> kind of inter thread message passing [17:22:33] <asynco> thank you so much [17:22:43] <temporalfox> I don't know how mongo is implemented actually [17:22:44] <asynco> yeah, I see ! [17:23:05] <asynco> tha mongoAsync driver uses netty [17:23:11] <temporalfox> ok [17:23:14] <asynco> so will spawn his own eventloop [17:23:21] <temporalfox> I think one improvement [17:23:28] <temporalfox> would to reuse the netty event loop in mongo client [17:23:29] <temporalfox> the same [17:23:36] <temporalfox> then it would stick to the same thread [17:23:45] <asynco> how can I do that ? [17:23:49] <asynco> that would be awesome [17:24:09] <temporalfox> like explained here [17:24:09] <temporalfox> [17:24:21] <temporalfox> if Mongo has opportunity to specify the Netty event loop to use [17:24:30] <temporalfox> then it could do like in this article [17:24:36] <temporalfox> and reuse the Context event loop [17:24:41] <temporalfox> look at the client part [17:24:52] <asynco> yep, going to read [17:24:55] <temporalfox> this doc sorry [17:25:04] <asynco> ok [17:25:06] <asynco> let me see [17:25:12] <temporalfox> [17:25:41] <temporalfox> in this case we would not need anymore runOnContext [17:25:53] <temporalfox> just executeFromIO [17:26:00] <asynco> yeah, because we are on the same EL [17:26:08] <asynco> great ! [17:26:35] <asynco> are you Tim Fox ? [17:26:42] <temporalfox> no [17:26:44] <temporalfox> I am julien viet [17:27:01] <asynco> oh, ok ! thank you julien [17:27:31] <asynco> and thank you for you job :) [17:27:36] <temporalfox> thanks! [23:47:47] * ChanServ sets mode: +o temporalfox

[23:58:40] <AlexLehm> temporalfox: i started writing a reply in the group to mention the netty issue, but i have not finished it yet

[23:58:57] <temporalfox> AlexLehm ok cool

[23:59:02] <temporalfox> thanks for carring :-)