Differences

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

@@ Line 1: / Line 1: @@
+[03:04:38] *** ChanServ sets mode: +o purplefox
+[04:48:07] *** ChanServ sets mode: +o temporalfox
+[09:27:48] <Anssi_> Hello..
+[09:29:37] <Anssi_> Just asking Memory leak related question, we're using vertx 4 and seems that when we run it smaller vm with 8G memory, it doesn not release native memory and eventually oom killer kills the process. After we added more memory, memory consumption looks better and it looks like that java is not leaking anymore native memory.
+[09:30:50] <Anssi_> has others observe similar thing, could be it something in the library implementation that could cause this.
+[11:30:09] <Anssi_> oops vertx 2 i meant.
+[11:30:33] *** ChanServ sets mode: +o temporalfox
+[11:35:10] <Sticky> given how much vertx 2 messed with classloaders its entierly probable that it was leaking metaspace
+[11:40:09] <Anssi_> wer're still running 7
+[11:41:01] <Anssi_> ..but lets see how it evolves. Moving to 8 in near future
+[11:48:25] <Sticky> you are leaking native in 7?
+[11:53:51] <Anssi_> Yeah. Oom killer kills if one big message comes in. We're looking the issue atm. Need to verify with the increased os memory but the os free mem graph looks just, more stable than before.
+[11:58:34] <Sticky> and you are sure that A) it is native memory not heap and B) it is java that is increasing in memory, not some other app and oom killer chooses the java process as the best candidate to free up memory even though its memory is stable
+[12:05:17] <Anssi_> Sticky: A) Yes, graphs does not show increase in java heap usage. B) Yes, Java process is taking more native memory.
+[12:55:29] <Anssi_> Looks like the issue is still there. Thanks for the ideas, we review the code if there is something funny. Thanks :)
+[14:52:25] *** ChanServ sets mode: +o temporalfox
+[16:40:54] *** ChanServ sets mode: +o purplefox
+[16:48:07] *** ChanServ sets mode: +o temporalfox
+[17:05:12] <skender> Hi, im having trouble with the auto-redeploy feature. When i launch a verticle via launcher.dispatch(new String[] {"run", "org.test.test.TestVerticle", "--redeploy=**\\*.java"}); im stuck in a loop of "Starting the vert.x application in redeploy mode"
+[17:05:34] <skender> when i do it in the command line it works as expected
+[17:15:15] <pbh> Hi folks, I'm using a NetSocket and was wondering if it is safe to use the buffer passed in the handle() method outside the scope of the handler, or if I need to make a copy.  In other words, is NetSocket going to be writing new data to that same buffer object?
+[17:22:38] <Sticky> not 100% but looking at the code I think no, make a copy
+[17:36:51] <stampy88> anyone have time to look at a PR?
+[17:40:57] <stampy88> https://github.com/eclipse/vert.x/pull/1198/files
+[18:08:59] <gemmellr> chirino: raised a new PR with some updates: https://github.com/vert-x3/vertx-proton/pull/9
+[19:51:09] <chirino> purplefox: can we make gemmellr_afk a committer to vertx-proton?
+[20:33:05] <temporalfox> chirino I can do it
+[20:33:11] <temporalfox> what is his github id ?
+[20:34:55] <temporalfox> I believe that he should before proposed as commiter on vertx-commiters list though
+[20:35:23] <temporalfox> chirino yes we need to do that before
+[20:37:27] <temporalfox> chirino you should send an email to vertx-commiters google group and propose him as commiter and get votes
+[20:37:33] <temporalfox> see https://github.com/vert-x3/wiki/wiki/Vert.x-3-Official-stack-and-component-maintainers
+[20:37:45] <temporalfox> "New Vert.x committers can be proposed by existing committers and must be voted in by a majority of existing Vert.x committers."
+[21:06:23] <purplefox> temporalfox: +1
+[21:25:33] <chirino> thx!