Differences

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

Link to this comparison view

irc:1463954400 [2017/05/27 13:44] (current)
Line 1: Line 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