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> https://vertx.ci.cloudbees.com/job/alexlehm-vert.x3-core-wip/76/console
[00:39:20] <AlexLehm> actually I think in the most recent build it doesn't happen anymore https://vertx.ci.cloudbees.com/job/alexlehm-vert.x3-core-wip/77/console
[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 http://vertx.io/blog/vert-x3-says-hello-to-npm-users/ , 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> https://groups.google.com/d/msg/netty/wJ-fzhsSMx8/aEXf8z5SBAAJ
[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> https://groups.google.com/forum/#!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 http://ix.io/16o4
[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> https://github.com/netty/netty/pull/5569#issuecomment-234616050
[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