Differences

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

Link to this comparison view

irc:1472594400 [2017/05/27 13:44] (current)
Line 1: Line 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