Differences

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

Link to this comparison view

irc:1468879200 [2017/05/27 13:44] (current)
Line 1: Line 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>​ https://​github.com/​eclipse/​vert.x/​tree/​netty-4.1.3.Final-bare
 +
 +[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>​ https://​vertx.ci.cloudbees.com/​job/​alexlehm-vert.x3-core-wip/​65/​console
 +
 +[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 https://​github.com/​netty/​netty/​commit/​27520f5208535935757014744647854f86286d37
 +
 +[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 https://​vertx.ci.cloudbees.com/​job/​alexlehm-vert.x3-core-wip/​66/​console
 +
 +[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 https://​vertx.ci.cloudbees.com/​job/​alexlehm-vert.x3-core-wip/​68/​console
 +
 +[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 https://​vertx.ci.cloudbees.com/​job/​alexlehm-vert.x3-core-wip 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