[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