This version (2017/05/27 13:44) is a draft.
Approvals: 0/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