Differences

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

Link to this comparison view

irc:1464127200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:00:20] <​ChicagoJohn>​ ive added line doc to the best of my ability
 +
 +[00:00:26] <​temporal_>​ long one :-)
 +
 +[00:01:02] <​temporal_>​ I think the multipl call is because Rx subscription in vertx are unicast
 +
 +[00:01:18] <​ChicagoJohn>​ can you rephraise?
 +
 +[00:02:04] <​temporal_>​ usually an Observable returned by vertx-rx cannot have multiple subscriptions
 +
 +[00:02:29] <​temporal_>​ I think you are a bit abusing of rx in your code
 +
 +[00:02:30] <​temporal_>​ like
 +
 +[00:02:41] <​temporal_>​ login.toObservable().flatMap(this::​initializeBuffer).reduce(Buffer::​appendBuffer)
 +
 +[00:02:58] <​temporal_>​ ah no
 +
 +[00:02:58] <​temporal_>​ what is "​login"​ ?
 +
 +[00:03:03] <​temporal_>​ ah it's client request
 +
 +[00:03:40] <​ChicagoJohn>​ login is an http call.  and the initialize/​buffer append is pulling all of the http response body all into one buffer. ​ so i have the full json result
 +
 +[00:04:20] <​temporal_>​ my opinion is that in your case you could simply do without rx
 +
 +[00:04:26] <​temporal_>​ for this part
 +
 +[00:04:36] <​temporal_>​ rx is nice if you have complex transformation or want coordination
 +
 +[00:05:01] <​ChicagoJohn>​ i was using vertx-when to give me a promise like code structure. ​ to flatten out all the callbacks
 +
 +[00:05:16] <​ChicagoJohn>​ and i was giving it a go using rx.  should i stick with vertx-when?
 +
 +[00:05:26] <​temporal_>​ I see, but I think in this case the callback are simple
 +
 +[00:05:32] <​temporal_>​ can you show me the vertx-when code ?
 +
 +[00:06:08] <​temporal_>​ I think what is difficult with callback is when you need coordination
 +
 +[00:06:15] <​ChicagoJohn>​ http://​paste.ofcode.org/​Et6bvaWAKQmCzCJuJkGKMu
 +
 +[00:06:21] <​temporal_>​ i.e you have two async calls and would like to be aware of the coordination of both
 +
 +[00:06:27] <​ChicagoJohn>​ bingo
 +
 +[00:06:57] <​ChicagoJohn>​ thats what i need.  the underlying code we are working with requires a lot of do http X then on that result, do http Y
 +
 +[00:06:58] <​temporal_>​ what is whenHttpClient ?
 +
 +[00:07:09] <​ChicagoJohn>​ that is using vertx-when
 +
 +[00:07:13] <​temporal_>​ yes but you do them sequentually
 +
 +[00:07:21] <​ChicagoJohn>​ this is correct
 +
 +[00:07:26] <​temporal_>​ so it may seem nested
 +
 +[00:07:32] <​temporal_>​ but the code remains easy to follow imho
 +
 +[00:07:36] <​temporal_>​ I'm tlaking if you do
 +
 +[00:07:43] <​temporal_>​ two http client requests in paralellel
 +
 +[00:07:51] <​ChicagoJohn>​ no not at this time
 +
 +[00:07:52] <​temporal_>​ and would like to know if both are OK
 +
 +[00:07:59] <​ChicagoJohn>​ currently just sequential
 +
 +[00:08:16] <​temporal_>​ there is no silver bullet to async code
 +
 +[00:08:22] <​temporal_>​ and everyone has to deal with it
 +
 +[00:08:26] <​temporal_>​ in some way or another
 +
 +[00:08:28] <​ChicagoJohn>​ you are very correct.
 +
 +[00:08:58] <​temporal_>​ yes
 +
 +[00:09:06] <​temporal_>​ going to twitt it :-)
 +
 +[00:09:10] <​ChicagoJohn>​ so i have it working with vertx-when doing sequential http calls. ​ if that is your suggestion, then i will continue with that.
 +
 +[00:09:21] <​temporal_>​ recenltyt we have in 3.3
 +
 +[00:09:28] <​temporal_>​ composition on Future
 +
 +[00:09:35] <​temporal_>​ so you create a vertx Future
 +
 +[00:09:42] <​temporal_>​ and then you can use compose/map
 +
 +[00:09:58] <​ChicagoJohn>​ so its similar to that of promises
 +
 +[00:09:58] <​temporal_>​ but it's not integrated with ReadStream/​WriteStream though
 +
 +[00:09:58] <​temporal_>​ it's more for AsyncResult
 +
 +[00:10:11] <​temporal_>​ imho what should be done is rather a better HttpClient API for such calls
 +
 +[00:10:18] <​temporal_>​ so if you do a request
 +
 +[00:10:21] <​temporal_>​ it would rather be
 +
 +[00:10:42] <​temporal_>​ client.get(....,​ Handler<​AsyncResult<>>​ -> { ... });
 +
 +[00:10:50] <​temporal_>​ so Future would work here
 +
 +[00:11:16] <​temporal_>​ so this leaves room for improvements :-)
 +
 +[00:13:02] <​ChicagoJohn>​ agreed. ​ if there was first party support for something like '​promises'​ that would be grand. ​ i.e. sequential but dependent http calls/ callbacks
 +
 +[00:13:38] <​ChicagoJohn>​ my only case against vertx-when (a promise library for java which can handle vertx) is that it is 3rd party. and in theory, the dev could drop support at any moment
 +
 +[00:14:10] <​ChicagoJohn>​ i looked into vertx-utils as well but again, that is also thrid party
 +
 +[00:15:46] <​ChicagoJohn>​ thanks for the help, ill be looking forward to 3.3  as a side note, when you do publish 3.3  a code sample for chanining requests would be most appreciated
 +
 +[00:17:19] <​ChicagoJohn>​ there are samples for rx but they stop at  goDoThisAsync(r ->  getDoThatAsync()) ​ However they never show the implementation of the inner http call
 +
 +[00:22:22] <​AlexLehm>​ temporal_: should the CaseInsensitiveHeaders class have a proper equals method? I think it currently only does object equals which is not right
 +
 +[13:52:45] <​chandan__>​ hi
 +
 +[13:52:50] <​chandan__>​ any here for help
 +
 +[13:53:35] <​Guest9459>​ I have some issue running vertx application
 +
 +[13:53:59] <​Guest9459>​ ????
 +
 +[13:54:46] <​Guest9459>​ he anyone
 +
 +[13:54:49] <​Guest9459>​ ?
 +
 +[13:54:53] <​Guest9459>​ ??
 +
 +[13:54:55] <​Guest9459>​ ??????
 +
 +[13:55:15] <​Guest9459>​ i am not able to run vertx using npm start
 +
 +[13:55:29] <​Guest9459>​ it will be great if any one can help me
 +
 +[14:04:08] <​Guest9459>​ i am using npm on windows
 +
 +[14:04:18] <​Guest9459>​ for vertx-web-full
 +
 +[14:04:30] <​Guest9459>​ {   "​name":​ "​vertxdemo", ​  "​private":​ true,   "​dependencies":​ {     "​vertx3-full":​ "​*" ​  ​}, ​  "​scripts":​ {     "​start":​ "​./​node_modules/​.bin/​vertx run server.js" ​  ​}, ​  "​version":​ "​1.0.0", ​  "​main":​ "​server.js", ​  "​devDependencies":​ {},   "​author":​ "", ​  "​license":​ "​ISC"​ }
 +
 +[14:04:43] <​Guest9459>​ this what in my package.json
 +
 +[14:05:23] <​Guest9459>​ whenever i use npm start
 +
 +[14:05:28] <​Guest9459>​ its showing error
 +
 +[14:28:21] <​Sticky>​ whwats the error?
 +
 +[14:29:13] <​Sticky>​ not that I will be able to help, never used vertx and npm, but I doubt anyone is going to be of any help without the error
 +
 +[14:31:46] <​Guest9459>​ 0 info it worked if it ends with ok 1 verbose cli [ '​C:​\\Program Files\\nodejs\\node.exe',​ 1 verbose cli   '​C:​\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',​ 1 verbose cli   '​start'​ ] 2 info using npm at 3 dot 3.12 3 info using node at v5 dot 5.0 4 verbose run-script [ '​prestart',​ '​start',​ '​poststart'​ ] 5 info lifecycle vertxdemo at 1 dot 0.0~prestart:​ vertxdemo at 1 dot 0.0 6 silly lifecycle vertxdemo at 1 dot 0.0~prestart:​ no script for prestart, conti
 +
 +[14:32:03] <​Guest9459>​ I pasted the error
 +
 +[14:32:27] <​Sticky>​ looks like it got cut off
 +
 +[14:32:36] <​Sticky>​ ends at "no script for prestart, conti"
 +
 +[14:33:06] <​msavy>​ suggest you try https://​gist.github.com
 +
 +[14:33:23] <​Guest9459>​ 6 silly lifecycle vertxdemo at 1 dot 0.0~prestart:​ no script for prestart, continuing 7 info lifecycle vertxdemo at 1 dot 0.0~start: vertxdemo at 1 dot 0.0 8 verbose lifecycle vertxdemo at 1 dot 0.0~start: unsafe-perm in lifecycle true 9 verbose lifecycle vertxdemo at 1 dot 0.0~start: PATH: C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin;​C:​\vertx_test\node_modules\.bin;​C:​\ProgramData\Oracle\Java\javapath;​C:​\Program Files (x86)\Java\jdk1.7.0\bin;​C:​\Program Fi
 +
 +[14:33:45] <​Sticky>​ still cut off
 +
 +[14:33:51] <​Sticky>​ use gist
 +
 +[14:34:21] <​Guest9459>​ https://​gist.github.com/​anonymous/​86d781f248366efafc1e0e85f9906989
 +
 +[14:34:26] <​Guest9459>​ thanks for the suggestion
 +
 +[14:44:15] <​Guest9459>​ @sticky have you used ?
 +
 +[14:44:20] <​Guest9459>​ that link
 +
 +[14:44:26] <​Guest9459>​ can you help me
 +
 +[14:45:13] <​Guest9459>​ why vertx community is not so active like ndoejs /
 +
 +[14:45:34] <​Sticky>​ we are about 1/1000000th the size
 +
 +[14:45:47] <​msavy>​ i'm not a nodejs expert, unfortunately. there'​s nothing particularly obvious that stands out to me in the error.
 +
 +[14:46:20] <​msavy>​ possibly would require trying out different version(s) of npm and nodejs
 +
 +[14:46:39] <​Guest9459>​ @msavy hmmm
 +
 +[14:46:48] <​Sticky>​ well it seems to me that it is trying to cd to c:​\vertx_test and run "vertx run server.js"​
 +
 +[14:46:57] <​Sticky>​ so if you do that manually what happens?
 +
 +[14:47:17] <​Guest9459>​ same error
 +
 +[14:47:31] <​Sticky>​ which is what?
 +
 +[14:48:02] <​Guest9459>​ https://​gist.github.com/​anonymous/​86d781f248366efafc1e0e85f9906989
 +
 +[14:48:39] <​Sticky>​ that doesnt show just the error from running "vertx run server.js"​
 +
 +[14:48:50] <​msavy>​ are you writing your own code here or using a public example
 +
 +[14:49:24] <​Guest9459>​ i am using following this example http://​vertx.io/​blog/​vert-x3-real-time-web-apps/​
 +
 +[14:50:16] <​msavy>​ i'll quickly see if it works for me.
 +
 +[14:50:39] <​Guest9459>​ okay thanks
 +
 +[14:50:48] <​Guest9459>​ i am trying this on windows 8
 +
 +[14:50:56] <​msavy>​ yes, that seems unfortunate :)
 +
 +[14:51:21] <​Guest9459>​ npm version 3.3.12
 +
 +[14:51:29] <​Guest9459>​ :(
 +
 +[14:56:48] <​msavy>​ Guest9459, Sticky: it works fine for me
 +
 +[14:57:10] <​Guest9459>​ on which system you are trying ?
 +
 +[14:57:21] <​Guest9459>​ and your npm version
 +
 +[14:57:32] <​msavy>​ i'm using a UNIX-y system. OS X.
 +
 +[14:57:37] <​msavy>​ NPM 3.8.9
 +
 +[14:57:49] <​msavy>​ node v6.2.0
 +
 +[14:58:28] <​Guest9459>​ okay thanks let me install ubuntu and give a try , I can't afford mac :(
 +
 +[14:58:28] <​msavy>​ Guest9459: also, i notice you seem to have Java 7 on your path
 +
 +[14:59:15] <​msavy>​ you need java 8+ for running vert.x
 +
 +[14:59:35] <​msavy>​ `java -version` returns what?
 +
 +[15:00:19] <​Guest9459>​ 1.8.0_77
 +
 +[15:03:42] <​msavy>​ a quick google search seems to indicate it's a windows problem
 +
 +[15:03:48] <​msavy>​ suggest you try a linux VM
 +
 +[15:04:30] <​Guest9459>​ okay thanks for your help
 +
 +[15:04:46] <​Guest9459>​ will be back if have more doubt
 +
 +[15:04:48] <​msavy>​ easiest would be virtualbox
 +
 +[15:04:49] <​Guest9459>​ :)
 +
 +[16:11:22] *** ChanServ sets mode: +o temporalfox
 +
 +[17:41:24] <​burrsutter>​ newbie question[unknown:​hellip]if [unknown:​ldquo]vertx run my-verticle.js -cluster[unknown:​rdquo] works, what is the [unknown:​ldquo]fat jar[unknown:​rdquo] equivalent?
 +
 +[17:41:34] <​burrsutter>​ java -jar myvert-far.jar ?
 +
 +[17:43:43] <​burrsutter>​ I am going to guess [unknown:​ldquo]java -jar myvert-far.jar -cluster[unknown:​rdquo]
 +
 +[19:48:04] <​msavy>​ burrsutter: as i recall, yes
 +
 +[19:48:42] <​burrsutter>​ msavy: that seems to enable clustering[unknown:​hellip]but my cluster does not form[unknown:​hellip]the members do not find each other[unknown:​hellip]more exploration :-)
 +
 +[19:49:30] <​msavy>​ burrsutter: are you connected to the VPN
 +
 +[19:49:39] <​burrsutter>​ msavy: no, I know that trick
 +
 +[19:49:44] <​burrsutter>​ msavy: :-)
 +
 +[19:49:45] <​msavy>​ burrsutter: i found it caused all kinds of mayhem
 +
 +[19:50:08] <​burrsutter>​ I even tried the Vert.x 2 trick of -cluster-host 192.168.1.11 (my laptop[unknown:​rsquo]s current ip address)
 +
 +[19:55:23] <​msavy>​ if you're using hazelcast there are a good number of hints here - http://​vertx.io/​docs/​vertx-hazelcast/​
 +
 +[19:55:35] <​msavy>​ may be a multicast issue if you're using OS X [;-)]
 +
 +[19:56:13] <​burrsutter>​ msavy: aha, thank you
 +
 +[19:56:31] <​msavy>​ when i was writing apiman'​s gateway i hit a few issues, but i recall it being fairly easy to overcome
 +
 +[21:03:22] *** ChanServ sets mode: +o temporal_
 +
 +[23:42:44] <​AlexLehm>​ temporal_: is the bootstrap.handler necessary when the initChannel method is empty?
 +
 +[23:42:54] <​AlexLehm>​ https://​github.com/​vietj/​vert.x/​blob/​socks-proxy/​src/​main/​java/​io/​vertx/​core/​http/​impl/​ConnectionManager.java#​L383