Differences

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

Link to this comparison view

irc:1469138400 [2017/05/27 13:44] (current)
Line 1: Line 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