Differences

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

Link to this comparison view

irc:1456700400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[10:37:20] <​aesteve>​ hi everyone, hi temporal_
 +
 +[10:37:28] <​temporal_>​ hi arnaud aesteve
 +
 +[10:37:34] <​temporal_>​ what's up ?
 +
 +[10:37:51] <​aesteve>​ a kinda urgent question
 +
 +[10:37:54] <​aesteve>​ :P
 +
 +[10:38:07] <​aesteve>​ I can't find any info re. httpclient and proxies
 +
 +[10:38:19] <​temporal_>​ re. ?
 +
 +[10:38:24] <​aesteve>​ regarding
 +
 +[10:38:27] <​temporal_>​ ah
 +
 +[10:38:53] <​temporal_>​ you have to do it manually
 +
 +[10:39:07] <​temporal_>​ we have some spec for a more advanced HTTP client supporting that though
 +
 +[10:39:29] <​aesteve>​ we definitely should that's a major pitfall
 +
 +[10:40:08] <​aesteve>​ I guess I have to reverse engineer the way the proxy works
 +
 +[10:40:09] <​temporal_>​ I've done it in http service factory
 +
 +[10:40:11] <​temporal_>​ https://​github.com/​vert-x3/​vertx-http-service-factory/​blob/​master/​src/​main/​java/​io/​vertx/​ext/​httpservicefactory/​HttpServiceFactory.java
 +
 +[10:40:29] <​temporal_>​ https://​github.com/​vert-x3/​vertx-http-service-factory/​blob/​master/​src/​main/​java/​io/​vertx/​ext/​httpservicefactory/​HttpServiceFactory.java#​L243
 +
 +[10:42:00] <​cescoffier>​ Hi aesteve, sorry was not listening...
 +
 +[10:42:20] <​aesteve>​ hi clement :)
 +
 +[10:43:04] <​cescoffier>​ Yes, right now we don't use proxyHost system variable
 +
 +[10:43:21] <​cescoffier>​ it needs to be done manually as in the HTTPServiceFactory
 +
 +[10:43:40] <​aesteve>​ I tried to and it didn't work but I'll give it another shot
 +
 +[10:43:44] <​cescoffier>​ I'm checking whether we have the feature in the "​advanced"​ HTTP client
 +
 +[10:43:58] <​cescoffier>​ yes it is
 +
 +[10:44:23] <​aesteve>​ what's the advanced HttpClient ?
 +
 +[10:45:21] <​cescoffier>​ it's an idea we have since a couple of weeks (maybe months). We would like to provide a more "​advanced"​ HTTP client on top of the low level one provided by Vert.x. Something with a feature set similar to OkHTTP, or the Apache HTTP Client
 +
 +[10:45:30] <​cescoffier>​ We have colelcted some feature we would like to see (https://​github.com/​vert-x3/​wiki/​wiki/​Better-HTTP-Client)
 +
 +[10:45:44] <​cescoffier>​ so far, we didn't start (at least on my side)
 +
 +[10:46:04] <​aesteve>​ the most needed would be proxy indeed and follow redirect
 +
 +[10:48:55] <​aesteve>​ the Host header solution doesn'​t work for me, I guess I have to reverse engineer how the proxy works
 +
 +[10:49:27] <​cescoffier>​ yes, the redirect (and max redirect) and proxy are definitely the most requested feature
 +
 +[10:50:14] <​cescoffier>​ if "​Host"​ does not work it means that the proxy use some other "​way"​ to detect the final host
 +
 +[10:50:25] <​cescoffier>​ do you know what is the technology used as proxy ?
 +
 +[10:51:15] <​aesteve>​ not really
 +
 +[10:51:34] <​aesteve>​ I know setting the hostname in gradle.properties / .npmrc works
 +
 +[10:51:56] <​aesteve>​ so this is probably not complicated since both are correctly dealing with the proxy
 +
 +[10:53:25] <​cescoffier>​ hum, there is a auth
 +
 +[10:53:53] <​cescoffier>​ you need the '​Proxy-Authorization'​ header
 +
 +[10:54:28] <​aesteve>​ I don't think so, because I didn't set any auth either for Gradle or npm
 +
 +[10:54:44] <​cescoffier>​ or '​Proxy-Authenticate'​ (can't remember which one it is)
 +
 +[10:55:44] <​cescoffier>​ because it probably adds this header automatically
 +
 +[10:55:53] <​cescoffier>​ It can also be '​WWW-Authenticate"​
 +
 +[10:57:14] <​aesteve>​ yes but where would they get the value from ?
 +
 +[10:58:14] <​cescoffier>​ will depends on the "​auth"​ mechanism
 +
 +[10:58:19] <​cescoffier>​ can be a digest, or something simpler
 +
 +[10:58:34] <​cescoffier>​ it's probably written somewhere in your settings
 +
 +[10:58:41] <​aesteve>​ which setting ?
 +
 +[10:58:50] <​cescoffier>​ our gradle properties
 +
 +[10:58:58] <​cescoffier>​ your gradle properties
 +
 +[10:58:58] <​aesteve>​ I created the file myself
 +
 +[10:59:14] <​cescoffier>​ just with the host ?
 +
 +[10:59:15] <​aesteve>​ as I said, I just set proxyHost and that's all
 +
 +[10:59:25] <​aesteve>​ same stuff with .npmrc
 +
 +[11:00:37] <​cescoffier>​ there error you have is a 401 ?
 +
 +[11:01:05] <​aesteve>​ connection refused, for now
 +
 +[11:01:44] <​cescoffier>​ try to add the X-Forwared-Host
 +
 +[11:02:38] <​cescoffier>​ what you can try to to get a curl request working
 +
 +[11:02:44] <​cescoffier>​ and look at the header passed
 +
 +[11:03:08] <​aesteve>​ I made some progress I got a bad request
 +
 +[11:03:24] <​aesteve>​ hope the body contains a nice error message
 +
 +[12:37:59] <​pplcf>​ I'm using clustered vertx and often I end up in situation when stopped vertx node keeps itself in event bus address map, so part of messages for that address go to nowhere and never replied
 +
 +[12:38:14] <​pplcf>​ io.vertx.core.VertxException:​ (TIMEOUT,​-1) Timed out waiting for a reply
 +
 +[12:38:46] <​pplcf>​ is it a bug or normal situation?
 +
 +[12:41:19] <​pplcf>​ I can see a "​nodeCrashedHandler"​ in ClusteredEventBus which tries to clean up crashed node data in subs map, but apparently it sometimes fails to do so
 +
 +[12:54:24] <​cescoffier>​ Hi pplcf
 +
 +[12:54:30] <​cescoffier>​ which cluster manager are you using ?
 +
 +[12:54:38] <​cescoffier>​ (and which version)
 +
 +[12:56:26] <​pplcf>​ hello
 +
 +[12:56:27] <​pplcf>​ io.vertx:​vertx-hazelcast:​3.2.1
 +
 +[12:57:26] <​cescoffier>​ are you using Hazelcast smart client, or is it just "​pure"​ Vert.x
 +
 +[12:58:39] <​pplcf>​ its "​pure"​ I guess, just VertxOptions options = new VertxOptions();​ and Vertx.clusteredVertx(options,​ res -> {
 +
 +[12:58:54] <​pplcf>​ i'm using quasar, if that relevant
 +
 +[13:00:14] <​cescoffier>​ quasar ? You mean vert.x sync ?
 +
 +[13:00:19] <​pplcf>​ yes
 +
 +[13:00:35] <​cescoffier>​ hum, I hope it's not related, I've no experience with sync
 +
 +[13:00:56] <​cescoffier>​ Does it happen every time a node is shutdown ?
 +
 +[13:05:11] <​pplcf>​ almost every time I rerun my app
 +
 +[13:05:31] <​pplcf>​ old instance keeps hanging around for some time
 +
 +[13:05:42] <​pplcf>​ so new instance connects to it
 +
 +[13:05:46] <​pplcf>​ a then first one dies
 +
 +[13:05:54] <​pplcf>​ http://​pastebin.com/​c4gZVv9J
 +
 +[13:06:14] <​cescoffier>​ so the "some time" is expected. It's the time the distributed map is propagated. But if "some time" means one minute, then it's not normal anymore
 +
 +[13:06:31] <​pplcf>​ oh, okay
 +
 +[13:07:17] <​cescoffier>​ do you know how big "some time" is ?
 +
 +[13:07:58] <​cescoffier>​ in addition, if someone sends a message, expecting the reply. The message is received, but the node having received the message dies in the mean time, it's also normal
 +
 +[13:08:44] <​cescoffier>​ from the log, you have a small cluster right ?
 +
 +[13:11:58] <​pplcf>​ it's my dev machine actually, lol, but i'm planning 2-3 nodes for production
 +
 +[13:12:19] <​pplcf>​ as I can see this situation only possible when there are 2 nodes
 +
 +[13:12:36] <​pplcf>​ and one dies unexpectedly
 +
 +[13:13:18] <​pplcf>​ "The message is received, but the node having received the message dies in the mean time" - this is not the case, address of "​crashed"​ node keeps hanging around forever
 +
 +[13:13:40] <​pplcf>​ so every 2nd request is routed there
 +
 +[13:14:29] <​cescoffier>​ so, definitely a bug, can you open an issue on vertx-hazelcast ? I will have a look
 +
 +[13:15:02] <​cescoffier>​ Actually, it might be related to https://​github.com/​vert-x3/​vertx-hazelcast/​issues/​13
 +
 +[13:15:37] <​cescoffier>​ your node crashes, or leaves ?
 +
 +[13:15:56] <​cescoffier>​ (well does it say good bye or does it crash completely)
 +
 +[13:20:39] <​pplcf>​ I'm actually not sure
 +
 +[13:21:46] <​cescoffier>​ anyway, open an issue with your observation,​ I'm going to write a repeatable tests and see if I can reproduce it
 +
 +[13:21:59] <​pplcf>​ okay, thank you
 +
 +[13:24:54] <​cescoffier>​ we are going to switch to HZ 3.6, it may be better after the update
 +
 +[21:05:20] *** ChanServ sets mode: +o temporalfox
 +
 +[22:11:25] *** ChanServ sets mode: +o temporalfox
 +
 +[22:22:53] *** ChanServ sets mode: +o temporalfox
 +
 +[22:28:56] *** ChanServ sets mode: +o temporalfox
 +
 +[22:34:55] *** ChanServ sets mode: +o temporalfox
 +
 +[22:55:20] *** ChanServ sets mode: +o temporalfox