This version (2017/05/27 13:44) is a draft.
Approvals: 0/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>

[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

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

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

[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

[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 (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 - [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>