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