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

[00:02:31] <temporalfox> there may be a problem as the close sequence change in the fork

[00:02:42] <temporalfox> and now it waits for the name resolver to shut down

[00:02:50] <temporalfox> so this delays the shut down

[00:03:12] <AlexLehm> ok, the eclipse/vert.x for gets the oom error

[00:03:23] <temporalfox> what is “gets” ?

[00:03:50] <AlexLehm> ok, the eclipse/vert.x fork gets the oom error

[00:04:11] <AlexLehm> the oom error appears there as well

[00:04:11] <temporalfox>

[00:04:26] <temporalfox> in which condition ?

[00:04:38] <temporalfox> you say “for gets”

[00:04:51] <AlexLehm> i meant the “fork gets”

[00:05:31] <temporalfox> what is “fork gets” ?

[00:05:52] <AlexLehm> the eclipse/vert.x fork gets the oom error

[00:06:16] <AlexLehm> when building the eclipse fork, the build process also causes an outofmemory error

[00:07:27] <AlexLehm> i will try to build the 4.1.3-bare fork now

[00:07:33] <AlexLehm> branch, sorry

[00:07:59] <temporalfox> ok

[00:08:43] <AlexLehm> my english skills and my typing skills do not make a good combination

[00:10:34] <AlexLehm> would it be possible that some tests are not able to close the vertx instance at all, i am getting a thread blocked error (for the build where I changed the close method to synchronous)

[00:11:37] <temporalfox> maybe

[00:11:44] <temporalfox> what I've done now is

[00:11:57] <temporalfox> change AsyncTestBase

[00:12:06] <temporalfox> to log the number of VertxThread

[00:12:26] <temporalfox> I'm trying the bare 4.1.3.Final

[00:13:38] <temporalfox> it is possible to get a list of all the threads

[00:14:08] <temporalfox> the number remains 0 or very low

[00:14:19] <temporalfox> ah now is is 22

[00:14:28] <temporalfox> (it's probably some unclosed instance)

[00:14:50] <temporalfox> at the end ofthe test it is 22

[00:15:22] <temporalfox> now I'm trying with the other branch

[00:16:31] <AlexLehm> with the final-bare branch, the outofmemory happens as well

[00:16:51] <AlexLehm>

[00:17:06] <temporalfox> ok

[00:17:21] <temporalfox> I'm going to push this logging

[00:17:29] <temporalfox> so we can see how the number of thread increases

[00:18:07] <temporalfox> see if we can observe a change

[00:20:47] <temporalfox> going to push that in bare branch

[00:23:06] <temporalfox> maybe this

[00:23:28] <temporalfox> vertx has a VertxThreadFactory

[00:25:15] <temporalfox> need to study this

[00:26:59] <temporalfox> AlexLehm can you retry the netty-4.1.3.Final-bare branch ?

[00:27:24] <AlexLehm> ok

[00:28:00] <AlexLehm> build is running

[00:34:10] <temporalfox> ok

[00:34:28] <temporalfox> now we should see the number of VertxThread

[00:34:30] <temporalfox> Starting test: NetTest#testMultipleServerClose VertxThread=22

[00:34:40] <AlexLehm> the thread count goes to about 15

[00:34:59] <temporalfox> yes but we need to ss oerally

[00:35:06] <temporalfox> to me it remains 0 most of the time

[00:35:09] <temporalfox> at the end it is 22

[00:35:42] <temporalfox> I see indeed

[00:35:43] <temporalfox> java.lang.OutOfMemoryError: GC overhead limit exceeded

[00:35:59] <temporalfox> in which linux did you reproduce it ?

[00:36:19] <temporalfox> so we can try to use Netty 4.1.2.Final

[00:36:56] <temporalfox> to see how itgoes

[00:37:06] <temporalfox> one possiblity is to make a dichotomic search

[00:37:08] <temporalfox> on netty commits

[00:37:44] <temporalfox> can you retun netty-4.1.3.Final-bare ?

[00:37:49] <temporalfox> it uses now 4.1.2.Final

[00:38:19] <AlexLehm> this is running on the jenkins (don't know what linux they use, probably fedora) and on ubuntu

[00:38:51] <AlexLehm> restarting the build

[00:39:38] <temporalfox> ok

[00:41:23] <temporalfox> let's see how it goes

[00:43:08] <temporalfox> butthe overall problem I see in hprof file is taht

[00:43:12] <temporalfox> there are 2,305 instances of “io.vertx.core.impl.VertxImpl”

[00:43:16] <temporalfox> which does not make sense to me

[00:43:37] <temporalfox> ah

[00:43:39] <temporalfox> a change in thread local map

[00:44:06] <temporalfox> InternalthreadLocalMap has a weak hasmap

[00:44:09] <temporalfox> the leak seems here

[00:45:46] <AlexLehm> ok, that was a change between 4.1.2 and 4.1.3 ?

[00:47:37] <temporalfox> I'm looking

[00:47:43] <temporalfox> the commit I pointed out earlier

[00:47:50] <temporalfox> seems to modify some of that

[00:48:06] <temporalfox> I need to understand this mechanism

[00:53:18] <temporalfox> note these are in weakhashmap

[01:06:37] <AlexLehm> the build with 4.1.2 does not create additional vertx threads, but it looks like it is stuck due to something else

[01:07:02] <AlexLehm> ok, i have to go to be, i am back to work tomorrow

[01:07:06] <temporalfox> ah yes

[01:07:07] <temporalfox> it needs

[01:07:11] <temporalfox> to use tc native 19

[01:07:14] <temporalfox> hold on

[01:07:18] <temporalfox> going to change that

[01:07:21] <temporalfox> then we can run the build :-)

[01:07:42] <AlexLehm> ok

[01:08:17] <temporalfox> I just pushed it

[01:08:37] <temporalfox> I'll look at tomorrow

[01:08:38] <temporalfox> have good night

[01:08:41] <temporalfox> I need to go to bed too ;-)

[01:09:11] <AlexLehm> ok, the build is starting

[01:09:14] <AlexLehm> good night

[01:09:20] <temporalfox> bye

[01:36:21] <NickNackName> Hello all, I am wondering if there is a way to get the termination code from a websocket client on close? I am working on a project now but the server is closing the connection and the owners need the code to debug.

[02:53:21] <NickNackName> I've been reading docs and playing with my coed but I still can't find a way to get the WS close code.

[02:53:25] <NickNackName> *code

[11:39:32] * ChanServ sets mode: +o temporalfox [12:04:00] * ChanServ sets mode: +o temporal_

[14:03:04] * ChanServ sets mode: +o temporalfox [16:24:58] * ChanServ sets mode: +o temporalfox

[17:25:32] * ChanServ sets mode: +o temporalfox [17:32:35] * ChanServ sets mode: +o temporalfox

[21:38:47] <kjar> can anyone point to good resources / references / documentation regarding vertx unit + gradle?

[22:10:19] *** ChanServ sets mode: +o temporalfox

[23:27:37] <AlexLehm> kjar: I dont think there are any, you should be able to run vertx-unit tests as regular groovy unit tests

[23:27:43] <AlexLehm> in gradle

[23:28:27] <kjar> AlexLehm: my issue was just getting things wired up so my gradle build would know what tests to invoke, ended up using the JUnit @Test annotations