This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[13:28:43] <AlexLehm> temporal_: thanks for fixing the issue yesterday, i have started implementing the tls checker, which turns out to be rather complicated due to strange cert classes in java

[13:28:56] <AlexLehm> that is not a problem related to vert.x though of course

[15:38:21] *** ChanServ sets mode: +o purplefox

[17:05:28] <nimtiazm> hi. I am new to vertx and trying to write a REST server which in turn consumes a remote REST service and returns the data to the user

[17:06:28] <nimtiazm> so far i[unknown:rsquo]ve managed to write something basic but when I try to hit the server (vertx service), it never returns and gets hung up[unknown:hellip] while in the console logs, i can see that the remote service has been consumed and the response body is also correct

[17:06:37] <nimtiazm> i[unknown:rsquo]ve posted the code here https://groups.google.com/forum/?fromgroups#!topic/vertx/iI-s2bijae4

[17:06:43] <nimtiazm> can anyone tell me what am i missing?

[17:58:55] <jtruelove_> hey man, just replied to your thread

[17:59:12] <jtruelove_> i think it's because you aren't setting the CONTENT_.. headers probably

[18:01:31] <jtruelove_> nimtiazm ^

[18:01:50] <nimtiazm> jtruelove_: let me try that

[18:04:42] <nimtiazm> jtruelove_: that worked

[18:04:49] <nimtiazm> but it was quite counter-intuitive

[18:05:04] <nimtiazm> because if i don[unknown:rsquo]t set the content length in a non-lambda operation, it works

[18:06:00] <jtruelove_> someone is setting it, Tim's comment is also correct in that you are closing the connection you don't want to do that

[18:06:41] <jtruelove_> no so such thing as a return payload without those headers

[18:07:06] <jtruelove_> HttpClient once you construct it is meant to be reused over and over unless it's truly single use

[18:08:34] <nimtiazm> jtruelove_: i guess i[unknown:rsquo]ll get used to it when i use the library more

[18:08:48] <nimtiazm> jtruelove_: thanks for your help so far. it worked

[18:08:48] <jtruelove_> think of HttpClient like a connection pool

[18:09:23] <jtruelove_> the max connections, which defaults to 5 last i looked, will gate how many outbound http requests you can make

[18:09:24] <nimtiazm> jtruelove_: yeah i read up the javadoc and was quite happy that it[unknown:rsquo]s easy to use without handling the pooling etc manually.. .but i did not know that response().close() will close the connection

[18:09:35] <nimtiazm> i thought it[unknown:rsquo]ll close the repsonse writer or so

[18:09:50] <jtruelove_> yeah that's just what end() is for

[18:09:58] <nimtiazm> jtruelove_: hmm

[18:11:04] <nimtiazm> jtruelove_: let me try a couple more things like file reading etc. i[unknown:rsquo]ll get back to you if i[unknown:rsquo]m stuck somewhere

[18:12:21] <jtruelove_> cool, if you want to look at a sample server doing a few different types of things check this out https://github.com/cyngn/ChronoServer

[18:40:02] <nimtiazm> what[unknown:rsquo]s the difference between httpclient get and getNow

[18:40:17] <nimtiazm> the doc has no difference except @Fluent annotation on getNow

[19:31:52] <jtruelove_> looks like fluent pattern chaining

[19:32:01] <jtruelove_> get returns the HttpClientRequest object

[19:32:20] <jtruelove_> getNow returns the HttpClient object so you can chain multiple calls together

[19:32:35] <jtruelove_> both are async given that you still need a response handler etc..