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

[00:00:57] <AlexLehm> I didn't do much this week, I got one fix approved by Norman in netty regarding the resolution of localhost in Windows

[00:05:03] <temporalfox> I saw that

[00:05:24] <temporalfox> anyway for 4.1.3.Final I don't know if we are going to use the dns name aresolver

[00:05:37] <temporalfox> as we need to handle the case with ndots=0

[00:05:47] <temporalfox> (that happen with docker compose)

[00:06:41] <AlexLehm> that is fixed in vert.x but not in netty currently?

[00:06:46] <temporalfox> no

[00:06:50] <temporalfox> it's not fixed

[00:06:57] <temporalfox> we should do two things in name resolver

[00:07:11] <temporalfox> 1/ load the ndots value from “/etc/resolv.conf”

[00:07:20] <temporalfox> 2/ check the behavior of ndots = 0 and test it

[00:07:27] <temporalfox> basically with ndots = 1 (the default)

[00:07:41] <temporalfox> resolving “foo” with a non empty search path

[00:07:47] <temporalfox> will never try to resolve “foo” absolutely

[00:07:55] <temporalfox> but with dnots=0 it does

[00:08:05] <temporalfox> and that's how docker compose configures the docker container

[00:11:19] <AlexLehm> i have to read up on docker a bit, I have not used that yet at all

[00:14:39] <AlexLehm> i assume that is all running in linux vms, so there should be no windows-specific issues

[00:16:41] <temporalfox> indeed

[00:24:12] <temporalfox> I may have found what the issue is

[00:24:23] <temporalfox> I'm checking

[00:26:32] <temporalfox> and no

[00:26:36] <temporalfox> it's not significant

[00:27:24] <temporalfox> actually yes it

[00:27:26] <temporalfox> is

[00:27:32] <temporalfox> was reading upside down

[00:28:11] <temporalfox> doing a new test to confirm

[00:28:17] <temporalfox> and I think I can go to bed :-)

[00:30:29] <temporalfox> cool

[00:30:41] <temporalfox> after searching for 4 days

[00:35:41] <temporalfox> AlexLehm can you point me a CLoudbees CI build where this happens ?

[00:35:45] <temporalfox> the outofmemoryerror

[00:37:21] <AlexLehm>

[00:39:20] <AlexLehm> actually I think in the most recent build it doesn't happen anymore

[00:41:56] <temporalfox> yes I've done some changes

[00:42:05] <temporalfox> to cleanup Vertx instances from VertxThread

[00:42:17] <temporalfox> but well there is still an OOM

[00:42:28] <temporalfox> I'm sending an email on Netty list

[00:42:30] <temporalfox> about it

[00:44:44] <temporalfox> are you on this list ?

[00:49:44] <AlexLehm> no

[00:51:32] <temporalfox> ok

[00:52:00] <mhaf> hello guys I really need your help

[00:52:12] <AlexLehm> the google groups one?

[00:52:31] <mhaf> I'm trying to run a simple exemple with npm the hello word exemple

[00:53:04] <mhaf> following this blog post , but I can't seem to do it

[00:53:14] <mhaf> throwing bunch of error in the console …

[00:54:31] <mhaf> can anyone help me please ?

[00:56:02] <AlexLehm> mhaf: sorry, i have 0 experience with the npm stuff

[00:57:02] <mhaf> :'(

[00:57:57] <AlexLehm> could you post your error messages to a pastebin maybe

[00:58:18] <AlexLehm> temporalfox: i joined the netty group now

[00:58:33] <temporalfox> I think netty google group is public

[00:58:50] <temporalfox> @mhaf post your question on vertx google group

[00:59:13] <mhaf> this is what the npm start throws C:\Users\zerub\Desktop\vertx>“$basedir/../vertx3-min/bin/vertx.bat” “[email protected]” The system cannot find the path specified.

[00:59:28] <temporalfox>

[01:01:35] <AlexLehm> mhaf: that looks like the path is not found, could you please ask the question in the group, maybe someone can take a look

[01:01:54] <temporalfox> AlexLehm actually I haven't tested that it fixes the problem on cloudbees because I would need a patched netty version in a snapshot repo or somethinglike that

[01:02:05] <temporalfox> but I'm fairly confident this is the thing

[01:02:05] <mhaf> do you have a link to the group ?

[01:02:16] <temporalfox> if by chance you can test that in your VM

[01:02:27] <AlexLehm>!forum/vertx

[01:02:36] <temporalfox> i.e take 4.1.3.Final + revert the commit I pointed out

[01:02:46] <temporalfox> and test that in the VM in which you observed the same issue

[01:02:49] <temporalfox> it would be awesome

[01:04:23] <AlexLehm> i will to tomorrow, i have to go to bed now

[01:04:31] <AlexLehm> its 1am in my TZ

[01:04:59] <temporalfox> same for me

[01:05:01] <temporalfox> going to bed

[01:05:11] <temporalfox> it's nor urgent per se

[01:05:12] <temporalfox> but if you can confirm that

[01:05:20] <temporalfox> it would be a very good thing

[01:06:18] <AlexLehm> yes ok i will tomorrow evening

[01:06:41] <temporalfox> thanks

[01:06:43] <temporalfox> bye

[01:06:44] <temporalfox> good night

[01:06:45] <AlexLehm> it would be possible to check out a forked netty and vertx in the same project in jenkins and build both

[01:06:48] <AlexLehm> good night

[09:39:05] * ChanServ sets mode: +o temporalfox [15:41:52] * ChanServ sets mode: +o temporalfox

[18:36:08] <AlexLehm> temporalfox: i think it still shouldn't work but the last build worked

[18:36:20] <temporalfox> ok AlexLehm

[18:36:29] <temporalfox> how are you sure of that ?

[18:36:38] <temporalfox> we need to be really sure

[18:36:54] <AlexLehm> when i run the build locally i can be sure which version is built

[18:36:57] <temporalfox> that's why I did not like to use the same version than the sonatype snapshots

[18:37:11] <temporalfox> there is always a doubt

[18:37:18] <AlexLehm> yes, you're right

[18:38:27] <AlexLehm> on a local build i can be sure that its the right version

[18:39:51] <temporalfox> ok

[19:20:48] <AlexLehm> when building netty and vert.x locally, it works

[19:21:15] <AlexLehm> i am getting some test failures but not out of memory

[19:23:01] <temporalfox> AlexLehm cool

[19:23:07] <temporalfox> can you tell Norman about it ?

[19:23:10] <temporalfox> in the mail thread

[19:23:34] <temporalfox> btw, how does it work/fail if you use regular Netty 4.1.4.Final-SNAPSHOT ?

[19:33:25] <dbh613> Has anyone used the vertx-mqtt-broker ?

[19:40:09] <AlexLehm> i will do a build with the 4.1.4 snapshot from the 4.1 head version

[19:40:11] <AlexLehm> that should fail

[19:52:16] <temporalfox> thanks AlexLehm

[19:52:28] <temporalfox> dbh613 no, but if you do, your feedback is welcome!

[19:53:27] <dbh613> Here is a quick scenario I'm playing with. I may try the mqtt broker. I'm running vertx on a raspberry pi b+, which has 512 MB ram, 700 Mhz processor.

[19:54:02] <dbh613> Running the eventbus / clustered mode so I can use event bus messaging between verticles is too memory/cpu intensive with hazelcast

[19:54:20] <dbh613> I'm looking for a more lightweight eventbus provider for vertx

[19:55:28] <dbh613> Currently, I'm using the shared data feature so my verticles running in the same vertx instance can see some shared-state data, but that approach has some drawbacks

[19:59:19] <temporalfox> dbh613 what is it ?

[20:15:19] <dbh613> temporalfox: Its an experimental app. While mobile, Collecting GPS data from GPSD (tcp client verticle) (rougly 1x per sec), and two other verticles getting sensor data which needs to be associated w/ the most recent GPS loc

[20:16:15] <dbh613> All being captured in db, but kind of rediculous not to associate sensor data w/ the latest gps loc, at time of sensing as that would require time-based correlation later on in post processing

[20:16:47] <dbh613> Basically its an excuse to learn vertx and play with toys I already have

[20:16:51] <dbh613> :P

[20:19:33] <dbh613> the shared data would ideally rather be messages on the eventbus

[20:19:36] <AlexLehm> ok, when i build thevert.x with the netty 4.1 branch, it causes out of memory, with the pull request from Norman it works

[20:19:43] <AlexLehm> so the diff fixes the issue

[20:22:17] <temporalfox> ah

[20:22:23] <temporalfox> can you confirm on github issue ?

[20:22:34] <temporalfox>

[20:25:39] <temporalfox> AlexLehm thanks for the check

[20:25:45] <AlexLehm> np

[20:25:48] <temporalfox> I think for now 4.1.3.Final is on-hold

[20:25:55] <temporalfox> and probably we should wait for a 4.1.4.Final

[20:26:07] <temporalfox> that contains other fixes

[20:26:10] <AlexLehm> yes

[20:26:20] <temporalfox> I need to make some more DNS work there anyway

[20:26:31] <AlexLehm> among the fixes is my localhost windows fix

[20:27:02] <temporalfox> I will send a mail on vertx-dev about this soon

[20:27:25] <temporalfox> I need to go to dinner

[20:27:26] <temporalfox> bye

[22:09:43] * ChanServ sets mode: +o temporalfox [23:08:28] * ChanServ sets mode: +o temporalfox