Differences

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

@@ 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