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

[08:38:04] <charlie7> I have a list of Futures and want to get notified (with a Future) when all Futures are either complete or failed. I tried with CompositeFuture.all and Composite.any but I was not able to implement the wanted behaviour. Any hints how to implement this?

[09:04:23] * ChanServ sets mode: +o temporalfox [12:09:00] * ChanServ sets mode: +o temporalfox

[16:51:37] * ChanServ sets mode: +o temporalfox [16:58:24] <AlexLehm> temporalfox: I will implement a fix for the localhost windows issue tonight (for netty and vertx), i have found the netty code that should be aes [16:58:28] <AlexLehm> easy to fix [16:58:30] <temporalfox> hi AlexLehm [16:58:34] <temporalfox> cool [16:58:40] <AlexLehm> Hello Julien [16:58:42] <temporalfox> I'm in a holiday rental this week [16:58:47] <temporalfox> so internet connectivity sucks [16:58:51] <AlexLehm> ah ok [16:59:00] <temporalfox> but I'm able to get enough for contributing [16:59:04] <AlexLehm> i assume your family would prefer if you do not work all the time :-) [16:59:05] <temporalfox> a bit [16:59:11] <temporalfox> no they are used to it :-) [16:59:17] <AlexLehm> ok [16:59:20] <temporalfox> and sometimes they sleep [16:59:35] <temporalfox> so best way to discuss is vertx-dev [16:59:42] <temporalfox> and late evening [16:59:46] <AlexLehm> ok [16:59:48] <temporalfox> on IRC [17:00:00] <temporalfox> I will have a look at the leak [17:00:35] <AlexLehm> i forgot to ask before, what is the planned date for the next version? [17:00:46] <temporalfox> I believe we aim around end of july [17:00:56] <AlexLehm> ok [17:01:03] <temporalfox> I need to file the CQ for Netty 4.1.3.Final [17:01:06] <temporalfox> will do that now [17:01:23] <temporalfox> I tried friday but eclipse website was not responding [17:03:07] <AlexLehm> btw i have sent a mail to the enquiries list about a possible security issue [17:06:01] <temporalfox> ok [17:06:02] <temporalfox> having a look [17:09:22] <temporalfox> internet is very slow [17:09:35] <AlexLehm> not a high priority thing problably [17:09:43] <AlexLehm> have kind of internet connection do you have? [17:10:00] <temporalfox> ok [17:10:00] <temporalfox> let's wait until it is resolved in netty [17:10:01] <temporalfox> so wifi [17:10:01] <temporalfox> borrowed from a neighbour [17:10:06] <temporalfox> close to the beach [17:11:24] <temporalfox> trying to get a google map link [17:30:46] * ChanServ sets mode: +o temporalfox

[20:18:50] <kjar> I'd like to include a request reference identifier (probably numeric, perhaps a UUID) with each request so I can isolate a requests log entries from the rest. does anyone have any alternative to generating one and passing it around everywhere you may log from?

[22:49:58] *** ChanServ sets mode: +o temporalfox

[23:31:37] <temporalfox> hi AlexLehm

[23:31:54] <AlexLehm> Hello Julien

[23:31:59] <temporalfox> can you tell me how you meet this problem ?

[23:32:08] <AlexLehm> the memory one or the localhost one?

[23:32:10] <temporalfox> do you have special maven settings ?

[23:32:11] <temporalfox> yes

[23:32:18] <temporalfox> do you have a special MAVEN_OPTS ?

[23:32:45] <AlexLehm> no, i just built the branch on jenkins or codeship and it got the oom error

[23:32:57] <temporalfox> can you show me the jenkins branch ?

[23:33:11] <temporalfox> so I can try push in this branch to see how it behaves

[23:33:15] <temporalfox> and/or print debug

[23:33:47] <AlexLehm> the branch is the netty branch you did, I just put it into my fork i think

[23:34:13] <AlexLehm> this one

[23:34:26] <temporalfox> I mean on jenkins

[23:35:40] <AlexLehm> ah, let me just put the settings back to how they were initially

[23:36:00] <AlexLehm> i tried to get the heap dump to work, but that hasn't changed the behaviour at all

[23:37:10] <AlexLehm> ah, actually i think I changed from maven default to maven 3.3.9, maybe that causes a change in behaviour

[23:37:21] <AlexLehm> ok, let me reset everything first

[23:38:13] <AlexLehm>

[23:39:20] <temporalfox> does it build the eclipse/vertx branch ?

[23:39:51] <temporalfox> and if you run it locally it fails too right ?

[23:40:06] <temporalfox> I am going to try twith a docker container maybe

[23:40:26] <AlexLehm> yes, it fails when i build locally with virtualbox

[23:40:43] <AlexLehm> should be the same with a docker image

[23:41:23] <AlexLehm> i can try to build the eclipse/vert.x branch next

[23:41:34] <AlexLehm> same issue happens here (different ci service)

[23:43:37] <temporalfox> I'm wondering how to see the difference

[23:45:18] <AlexLehm> it might be possible to run the build once with netty 4.1.1 and once with netty 4.1.3, if the issue is caused by netty, the oom should be only in 4.1.3

[23:46:10] <temporalfox> I don't think it's a netty problem

[23:46:19] <temporalfox> it may be a leak in vertx tests too

[23:46:23] <temporalfox> not closing some vertx instances

[23:46:40] <temporalfox> or not waiting for them to be closed

[23:46:51] <temporalfox> i.e call close()

[23:47:08] <AlexLehm> but if the master version works and the netty branch not, that is not likely

[23:47:09] <temporalfox> can you try in a branch

[23:47:14] <temporalfox> to modify Vert.close()

[23:47:21] <temporalfox> and make it synchronous

[23:47:30] <temporalfox> so use a latch

[23:47:40] <temporalfox> and test with that

[23:47:44] <temporalfox> to see how it goes

[23:48:09] <AlexLehm> ok

[23:48:17] <temporalfox> also there some instances

[23:48:21] <temporalfox> not managed

[23:48:43] <temporalfox> for instance in LocalEventBusTest we hae

[23:48:45] <temporalfox> have

[23:48:45] <temporalfox> vertx.close();

[23:48:45] <temporalfox> vertx = vertx();

[23:48:51] <temporalfox> vertx.close();

[23:48:51] <temporalfox> vertx = Vertx.vertx();

[23:48:55] <temporalfox> the first close() is async

[23:49:12] <temporalfox> and it may produce lot of garbage

[23:49:28] <temporalfox> etc…

[23:49:48] <temporalfox> what I suspect is that now it takes a bit more time to close vertx

[23:50:06] <temporalfox> because of the DNS resolvers that are closed

[23:50:18] <temporalfox> in the NameResolverGroup thing

[23:50:27] <temporalfox> there is one resolver per event loop

[23:51:55] <temporalfox> your other suggestion is to make a branch that simply upgrades Netty 4.1.3.Final without other changes and try it ?

[23:53:33] <AlexLehm> yes

[23:53:38] <temporalfox> going to do that

[23:53:43] <temporalfox> and give it to you

[23:53:50] <temporalfox> it's trivial

[23:56:38] <temporalfox> that being said 7000 vertx thread in your eclipse mat, it's quite a lot

[23:58:40] <AlexLehm> ok, i can do more than one build at once now, i am trying to build the eclipse fork on jenkins and i have changed the close method and try to build that on my local vm