Differences

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

@@ 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