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

[00:06:01] <AlexLehm> BadApe: java8

[00:06:18] <AlexLehm> or actually java7 for vertx 2.x and java8 for vertx 3.x

[00:08:15] <AlexLehm> temporal_: I think the pr1424 is ok

[00:26:06] <AlexLehm> temporal_: i read through pr1431, i am not sure if understand that good enough to evaluate the pr

[00:27:06] <AlexLehm> temporal_: I found an error in the adoc however, it looks like the parser doesn't understand {@literal -1}, that is empty in the generated files

[00:38:33] <BadApe> seems like it is openjdk 8

[00:39:52] <BadApe> docker seems like the way to go these days, but i've been using a .json config can i do something like vertx run abc.jar -config /etc/myapp/config.json

[09:59:57] <LostCoder> Where can I find the snapshot builds, are they hosted anywhere, or do I need to checkout and build myself?

[10:00:32] <LostCoder> specifically https://github.com/vert-x3/vertx-microservices-toolbox

[11:31:02] <cescoffier> LostCoder : there are on oss snapshot repository

[12:46:47] <LostCoder> Thanks.

[14:13:06] <blakki> hi. i'm using httpclient.get(..).setTimeout(15000).exceptionHandler(handler) and I'm getting my exception handler called twice. is this intentional or should it be only called once? first call is with java.util.concurrent.TimeoutException and second with io.netty.channel.ConnectTimeoutException

[15:46:02] <temporal_> blakki this is expected

[15:46:22] <temporal_> it can be disturbing, but exception handler is called for every event that is an exception

[15:52:34] <aesteve> hi everyone :)

[16:08:20] <temporal_> hi arnaud!!!

[16:08:58] <aesteve> hi Julien how is 3.3.0 going ? My mailbox is flooded by resolved issues so I guess fine ! :)

[16:09:22] <temporal_> it's progressing :-)

[16:09:29] <temporal_> code freeze is this week

[16:12:39] <temporal_> have you by chance looked at vertx unit ?

[16:13:16] <aesteve> re. the exception handling stuff ? No, not more than last time I was here

[16:13:19] <aesteve> sorry

[16:13:50] <aesteve> I was busy learning Elm / Kotlin unfortunately :/

[16:14:59] <blakki> temporal_: ok, thanks. I'm sending the httpresponse in the exceptionhandler and getting “response has already been written”. is there better way to fix this than adding a lock + checking response.ended()?

[16:15:36] <temporal_> are you writing a proxy or something ?

[16:15:44] <temporal_> (reverse proxy)

[16:16:42] <temporal_> I think one thing would be to allow to unset the handler maybe ?

[16:16:51] <temporal_> but yes otherwise you could check response ended

[16:18:10] <temporal_> aesteve you hipster

[16:18:27] <aesteve> I guess yes :D

[16:18:32] <aesteve> guilty

[16:37:09] <blakki> temporal_: I have multiple use cases but one example is authentication. can exception handler be called from multiple threads concurrently?

[16:44:44] <temporal_> why would that happen ? if you have mutliple concurren thread calling an handler it means you are not following the vertx model

[16:51:52] <blakki> I'm just asking could it happen as I'm getting two different timeouts to exception handler

[17:03:13] <blakki> and after rereading the documentation I understand it should not happen. thanks again :)

[17:12:06] <LostCoder> I need some help wrapping my head around “not blocking” programming. After 10 years of EE blocking programming, my brain is having issues switching gears.

[17:13:15] <LostCoder> I want to create a net client that reconnects “forever” (or until verticle is undeployed).

[17:13:39] <LostCoder> So what do I do on the closeHandler

[17:18:36] <LostCoder> I want to just call “createClient” again, but would that not eventually cause a stack overflow because of the recursion?

[17:27:39] <ChicagoJohn> connections arent typically reused. that sounds like something you would want to schedule.

[17:29:10] <BadApe> can i supply a .json config file to my app if i run it using vertx directly rather than creating a fat jar?

[17:51:01] <LostCoder> BadApe yes you can.

[17:52:31] <LostCoder> look under the “Run verticles” heading http://vertx.io/docs/vertx-core/java/

[17:53:04] <LostCoder> http://vertx.io/docs/vertx-core/java/#_run_verticles

[18:09:27] <BadApe> damn i couldn't see it

[18:09:34] <BadApe> i thought i searched that page for -conf

[18:24:30] *** ChanServ sets mode: +o temporalfox

[19:39:42] <BadApe> when running with vertx run, can i use logging options configured in a vertx-default-jul-logging.properties ?

[19:53:49] <namrood> BadApe you should configure logging as you configure logging in any app

[19:53:58] <namrood> the docs explain the process

[22:42:15] <melvinross> anyone ever have HTTPServer refuse HTTP & HTTPS connections after enabling SSL?

[22:58:58] <melvinross> different question, is it possible for an HTTPServer to be both HTTP and HTTPS simultaneously?

[23:00:35] <aesteve> melvinross: i don't think so

[23:00:45] <aesteve> did you explicitely set the port to 443 ?

[23:00:52] <aesteve> that's a common mistake

[23:01:09] <melvinross> i did at first, but it throws an exception about that

[23:01:14] <melvinross> so it's very clear that you shouldn't

[23:01:23] <melvinross> what i was doing was still doing listen(8080)

[23:01:33] <aesteve> what's the exception ?

[23:01:52] <melvinross> something about that port already being set

[23:01:57] <aesteve> I'm confused, I've done that a million times

[23:02:04] <aesteve> do you have some code to share ?

[23:02:14] <melvinross> you've done what a million times?

[23:02:34] <aesteve> setting up an HTTP / HTTPs server listening on ports 80/443

[23:02:58] <aesteve> you have to declare two servers, with two different HttpServerOptions

[23:03:06] <aesteve> but the same requestHandler

[23:03:08] <melvinross> yes that's what i've deduced myself

[23:03:20] <melvinross> which is why i asked if there was any other way

[23:03:58] <aesteve> I cannot guess if you don't show me your code unfortunately, sorry I'm trying to help :(

[23:04:10] <melvinross> oh i've managed to get it working

[23:04:46] <melvinross> originally i was doing server.listen(8080); server.listen(443); which is what throws an exception about the listening port already being set

[23:05:10] <melvinross> because i was under the wrong assumption that one HTTPServer instance could

[23:05:14] <melvinross> a. listen to both ports

[23:05:22] <melvinross> b. be both HTTP and HTTPS

[23:06:12] <melvinross> i got rid of explicitly setting 443, and then realized that my HTTPServer instance was SSL only and bound to port 8080 for SSL instead of 443

[23:06:25] <melvinross> which makes total sense now

[23:10:31] <melvinross> were you saying that you were having unexpected behavior when you explicitly set the port to 443 and only 443?

[23:10:52] <aesteve> no

[23:11:28] <aesteve> I was saying I was confused that creating 2 different http servers on 2 different ports wouldn't work, because that's what I'm doing almost on a daily basis

[23:11:42] <melvinross> ohhhh

[23:11:44] <melvinross> okay

[23:11:49] <melvinross> now we're on the same page

[23:12:37] <melvinross> yes that definitely works. I was just surprised that it was required, and was curious if there was another that I just didn't figure out

[23:47:12] <AlexLehm> temporalfox: hi Julien, I have added a bit of documentation for the proxy config and tried to improve the comments a bit, i think its mostly finished

[23:48:12] <temporalfox> ok

[23:48:17] <AlexLehm> i would like to squash the commits into one i guess since there are 16 commits until now

[23:48:17] <temporalfox> it should be merged this week :-)

[23:48:22] <temporalfox> as you want

[23:48:26] <temporalfox> I don't mind the different commits

[23:48:34] <temporalfox> meaning that it describe the work you have done

[23:48:43] <temporalfox> and that's the stream blood of open source

[23:50:47] <AlexLehm> yes, but i have changed too much back and forth when trying to find the event bug, too many log statements

[23:51:00] <temporalfox> ok

[23:51:04] <temporalfox> then squash it

[23:51:28] <temporalfox> don't forget doc

[23:51:35] <temporalfox> also it would be good to add examples

[23:51:41] <temporalfox> in vertx-examples repo

[23:51:49] <temporalfox> well more than good, it's mandatory :-)

[23:52:13] <AlexLehm> i have added the docu to the package-info files, i will do real examples next

[23:52:24] <temporalfox> great

[23:52:40] <temporalfox> looks like you have done some decent contribution to Vert.x networking for 3.3 :-)

[23:54:00] <aesteve> AlexLehm: you worked on the new features of HttpClient ?

[23:54:18] <AlexLehm> only the proxy support

[23:54:49] <temporalfox> alex worked on proxy support for SOcks and CONNECT

[23:54:54] <temporalfox> well

[23:54:59] <temporalfox> “contributed” is the right word :-)

[23:55:22] <aesteve> ah ok, cool !

[23:55:59] <aesteve> I had so much struggle in the past with proxies :\

[23:56:42] <AlexLehm> for vert.x?

[23:57:20] <aesteve> with vert.x yes, I think I ended with asking the question on the Google Group and you answered me iirc

[23:59:30] <AlexLehm> ah yes