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