This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[07:47:43] <myghty> temporalfox: well, my issue is, that in that case my router needs to translate httprequests to the right method call

[07:47:55] <myghty> or give every service proxy a single “handleRequest” methdo

[07:48:37] <myghty> where I think both approaches are not completely ideal…

[18:42:40] <brunoais> Hi. I'm having trouble setting up my development environment under the Eclipse IDE for vertx-web.

[18:42:54] <brunoais> As I run maven over the pom.xml file,

[18:42:59] <brunoais> I get:

[18:43:07] <brunoais> vertx-web\pom.xml [0:0]: Unused Import-Package instructions: [io.vertx.lang.rxjava.*, io.vertx.rxjava.core.*, io.vertx.rxjava.ext.auth.*, rx.*]

[18:43:21] <brunoais> \vertx-web\pom.xml [0:0]: Invalid package name: 'vertx-web'

[18:43:28] <brunoais> vertx-web\vertx-web\pom.xml [0:0]: Invalid package name: 'vertx-web-js'

[18:43:44] <brunoais> These are from “bnd-maven-plugin:3.2.0:bnd-process”

[18:45:05] <brunoais> I don't get how come they are invalid

[18:46:33] <brunoais> I'm also getting:

[18:46:33] <brunoais> Plugin execution not covered by lifecycle configuration: org.codehaus.gmavenplus:gmavenplus-plugin:1.5:compile (execution: default, phase: compile)

[18:48:05] <brunoais> I've tried to find how to setup the development environment but I only found: https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md

[18:48:12] <brunoais> That didn't help as much as I expected…

[18:48:52] <brunoais> brb

[19:34:58] <ewittman> temporalfox, question re: DockerProvider - the synchronization is necessary because requests can come in on a different thread than DockerServiceImporter publish/unpublish callbacks?

[19:47:56] <temporalfox> hi ewittman

[19:48:01] <ewittman> yo

[19:49:00] <temporalfox> at which line ?

[19:49:07] <temporalfox> in handle ?

[19:49:37] <temporalfox> servers could probably be a CopyOnWriteArrayList I think instead

[19:49:50] <temporalfox> there isn't yet much performance improvement

[19:49:55] <temporalfox> but yes, with docker it's quite dynamic

[19:50:19] <temporalfox> at the container come and go according to the DockerServieImporter as you said

[19:50:37] <ewittman> right - a number of the methods are synchronized, and there are additional synch blocks within start() and handle()

[19:50:55] <ewittman> just making sure that's to protect the dynamic list of servers and not something more that I'm not seeing

[19:51:14] <temporalfox> to be honnest there is not much thoughts in the current design

[19:51:19] <ewittman> :) fair enough

[19:51:24] <temporalfox> the goal was to make a prototype / proof of concept

[19:51:35] <temporalfox> to reuse and improve the ServiceDiscovery

[19:51:49] <temporalfox> because ServiceDiscovery was not flexible enough initially

[19:52:06] <temporalfox> so it helped to improve it

[19:52:19] <temporalfox> initally ServiceDiscovery backend was about import+export

[19:52:20] <ewittman> ok that makes sense

[19:52:29] <temporalfox> then we split it in separate Import / Export

[19:52:40] <temporalfox> so the reverse proxy only cares about one of them

[19:52:58] <ewittman> Well - I was just curious - I haven't touched the Docker stuff, since I'm actually using win10 and it uses some unix native code in the docker impl

[19:53:23] <temporalfox> https://traefik.io

[19:53:26] <temporalfox> it handles more than docker

[19:53:31] <ewittman> +1

[19:53:47] <temporalfox> and actually the ServiceDiscovery does these as well already

[19:53:59] <ewittman> I've added two new backends. One that expects the request to include a X-Proxy-To header. And one that will monitor a config file containing the list of servers to proxy to.

[19:54:00] <temporalfox> and we need a flat-file one

[19:54:24] <temporalfox> one thing is that the code for doing the http part should be factored out as much as possible in the proxy logic itself

[19:54:39] <temporalfox> ewittman ok I seee

[19:54:50] <temporalfox> the client says which server it wants to reach ?

[19:54:56] <temporalfox> yes good for the list

[19:54:56] <ewittman> right

[19:55:04] <ewittman> I thought that might good for the perf. testing guys.

[19:55:12] <ewittman> *might be

[19:55:23] <temporalfox> that's the current discovery docs http://vertx.io/docs/vertx-service-discovery/java/

[19:57:17] <ewittman> i'm not sure how much, if any, of what I'm doing is going to be useful to you. I'll get a PR to you tomorrow and you can have a look.

[19:58:01] <temporalfox> I think at least we want to focus on having a correct reverse proxy in most cases

[19:58:21] <ewittman> what you have already seemed to work pretty well

[19:58:37] <temporalfox> I think some case I don't know how to handle properly are failures

[19:58:46] <ewittman> ah yeah ok

[19:58:49] <temporalfox> if the client fails

[19:58:55] <temporalfox> how should the proxy behave

[19:58:58] <temporalfox> or the server fails

[19:58:59] <ewittman> yeah that gets tricky

[20:00:00] <temporalfox> specially if there is keep alive

[20:00:08] <temporalfox> I don't know if nginx supports pipelining

[20:01:34] <ewittman> right

[20:01:37] <ewittman> i'm not sure either

[20:01:56] <temporalfox> probably intiially we don't need to support pipelining

[20:02:30] <ewittman> i wonder how common keep alive is outside of web browsers… (e.g. REST clients)

[20:03:21] <temporalfox> vetx http client supports it

[20:04:45] <temporalfox> also another area is supporting CONNECT

[20:05:11] <temporalfox> AlexLehm probably knows better than me how a reverse proxy would support it :-)

[20:05:31] <temporalfox> but I think it's not the use case we need initially

[20:05:33] <ewittman> for tunneling?

[20:05:37] <temporalfox> yes

[20:21:13] <AlexLehm> ewittman: most http clients support keep-alive nowadays, e.g. the apache hc project

[20:21:33] <AlexLehm> CONNECT doesn't make much sense for a reverse proxy i guess

[20:21:49] <AlexLehm> not sure how nginx handles protocols other than http

[20:22:03] <ewittman> ok thanks

[20:22:18] <ewittman> i agree that it's not the target right now, certainly

[20:26:00] <AlexLehm> with a reverse proxy, it might make sense to support keep-alive on the server side and on the client side as well, but since the connections are not 1:1 it will be different connects

[20:32:22] <ewittman> that's a really good point actually

[20:35:03] <brunoais> Hi

[20:35:04] <brunoais> [ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.5:compile (default) on project vertx-web: Error occurred while calling a method on a Groovy class from classpath. InvocationTargetException: io/vertx/core/json/JsonObject : Unsupported major.minor version 52.0 → [Help 1]

[20:35:17] <brunoais> I get this when running: “mvn compile”

[20:35:20] <AlexLehm> that looks like a java version issue

[20:35:37] <AlexLehm> maybe you are using a java 7 or 6 for maven, but the classes are java8

[20:35:47] <brunoais> Hum…

[20:35:52] <AlexLehm> vertx is java 8 only

[20:35:55] <brunoais> I'll check javahome, then

[20:36:12] <brunoais> I have jdk for java 8

[20:36:41] <AlexLehm> hm, then the maven is choosing another jvm or class compatibility

[20:37:23] <ewittman> brunoais, try this: mvn -version

[20:37:31] <ewittman> Just to be sure of the jdk that maven is using

[20:37:50] <brunoais> Yeah… It was actually pointing to jdk for java 7

[20:38:08] <ewittman> That darn maven!

[20:38:16] <AlexLehm> there is a different between JAVA_HOME and JRE_HOME maybe?

[20:38:49] <AlexLehm> or its doing some kind of auto-detection of the jdk?

[20:38:58] <brunoais> It is reading JAVA_HOME env

[20:39:12] <brunoais> On my case, it was pointing to the old jdk7

[20:39:27] <brunoais> unfortunately… I can't get this to work with m2e T.T

[20:39:52] <AlexLehm> you can change to java 8 in eclipse as well I think

[20:40:12] <brunoais> It is already java 8

[20:40:24] <brunoais> I'm now trying to clean

[20:40:31] <brunoais> I'll give you the error in a min

[20:40:47] <brunoais> (if it still happens)

[20:42:27] <brunoais> Sounds like after running in the command line it solved its issues ^^

[20:43:21] <brunoais> AlexLehm, Any idea where the instructions on how to test changes are?

[20:43:37] <brunoais> … or is it limited to the automated tests?

[20:46:16] <AlexLehm> mvn test should run unit tests for the project

[20:46:29] <brunoais> So I guess… that's the only viable way…

[20:46:30] <brunoais> OK

[20:46:36] <brunoais> it's enough, I think

[20:46:44] <brunoais> thank you for helping

[23:23:07] *** ChanServ sets mode: +o temporalfox