Differences

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

Link to this comparison view

irc:1468792800 [2017/05/27 13:44] (current)
Line 1: Line 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 https://​github.com/​alexlehm/​vert.x/​tree/​netty-4.1.3.Final
 +
 +[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>​ https://​vertx.ci.cloudbees.com/​job/​alexlehm-vert.x3-core-wip/​
 +
 +[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 https://​codeship.com/​projects/​109359/​builds/​16594440 (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