Use a global HTTP server to support multiple verticles contributing routes independently

[MartinKersten]

Current Situation

Currently creating two HttpServer instances listening to the same port are not supported. Having multiple instances of the very same Verticle results in alternating choosing a individual instances HttpServer server to let one instance answer the request allowing multiple instances of the same Verticle to contribute routes to the same port.

Use cases

Being able to modularize an API and have multiple Verticles to contribute to the API on the very same (standard) port allows modularization and bundling actual functionality and the (HTTP)API making the functionality available in the very same Verticle. Having such 'self-contained' verticle allows for easier separation in subprojects, limit cross team communication. Also it allows to have projects (modules) for certain tasks and use these to bundle nodes and products reusing not only functionality but the (HTTP) API itself.

POC

I created my own implementation of a GlobalHttpServer that allows verticles to lookup the server for a given port and contribute routes+handlers. The server registers route and handler and once the route matches randomly choosing one handler to handle the request. The server ensures that the individual handler runs in the right context. The server compensates for different path parameter names.

Contribution

I can help with the contribution and provide some source code and input but my solution currently does not allow for verticles to stop (and have their handlers removed) as this is not part of my feature set.

[vietj]

that's a long known issue, perhaps we can revisit this in Vert.x 4

[vietj]

@MartinKersten I think the main issue currently is that an HTTP server request is couple to a given event-loop and it would work if we are able to dissociate an HTTP server request from an event-loop and associate to another event-loop. Did you find that in your investigation ?

[MartinKersten]

@vietj Julien I use a different approach but with limitations I do not care for at the moment.
(1) A GlobalHttpServer wraps an actual HttpServer instance
(2) The HttpServer instance is created + listens to port and lives in the context that first requests it
(3) Each registered handler is stored along with its context in a list of handlers with similar routes (map for pathParameter names)
(4) The GlobalHttpServer maps the same routes against the HttpServer instance
(5) The handler of the GlobalHttpServer instance acts as a proxy and randomly choses one of the registered handlers and executes it against the request context using the stored context.runOnContext(() -> theHandler.handle(rc));

Thats about it.

If you deregister a handler it is removed from the list.

Only drawback if you stop the verticle the http server is running in (its context) that might be something for you guys to think about but I do not need the functionality. One would have to be able to switch the event loop the http server is running in. And of cause it should be able to run multiple http server on different event loops but again I dont need this functionality.

But one thing I would try to do, if the context of the http server shuts down, just check what context's are still registered and just install a http server for the port using context.runOnContext and continue the game. But I never took a look into the shutdown hook capabilities and how it all decompses.

But you see by not making the HttpServer decoupling from something but just provide a different wrapper server, one can have the capabilities we are looking for without tampering with HttpServer and potential breaking stuff.

[MartinKersten]

The global server allowed me to get others on board with the whole vertx train as it eliminates the need for reverse proxies or extensive configuration to just transparently map different ports to a the same port or maintain an API layer all teams will have to sync on. So I guess its worth it to make something like the GlobalHttpServer available to people but saying where the current limitations and tradeoffs are.

[vietj]

@MartinKersten I think that what you do can introduce data races because you are using fully an http server request/response from another context

[wang007]

@vietj about this issue, I have an idea.

1. add VerticleGroup (or other name) class extends Verticle interface to support add sub Verticle.
2. VertilceGroup add sub Verticle about http server, but only one sub Vertilce listen port and shared Router (not data races in the same eventLoop)
3. deploy VerticleGroup