vertx-web: Routes established by 2 different Verticles result in failure due to apparent round robin routing.
Let’s say I have the following situation:
I have 2 Verticles, each of which wants to establish a different route under the same web server address. They can each create the HttpServer at that address and Vertx will transparently share a single server between them. However, the same is not true for any Routers they may create. They may chose to either:
- Each create their own Router and define routes independently.
- Use the Vertx shared data map to create a single Router which they share and create their routes under that.
Option 1 doesn’t work since when a request is received by the HttpServer it appears to choose between the 2 routers in a round robin fashion. This means that 1/2 the time instead of having the request processed you will instead get a response of <html><body><h1>Resource not found</h1></body></html>.
Option 2 doesn’t work unless you are willing to ensure that the verticles will never use an isolating classloader (a complete discussion of this can be found here – https://groups.google.com/forum/#!topic/vertx/PVf_734rr-w – the most recent postings starting around June 7th). Also as @purplefox observes this approach isn’t very “vertxy”.
I haven’t been around here long enough to know for sure, but to me option 1 is the most “vertxy” and is consistent with the way vertx handles the sharing of the Http server by multiple verticles. If that is shared then it seems intutive that the routers should be as well. If full sharing isn’t possible, perhaps another solution would be to have the server continue to look for a router that can handle the request before giving up.
Anyway, at some level I’m trying to figure out how we’re supposed to handle this. I want to have independent verticles that can contribute to the overall route tree and have the ability to dynamically add them without having to maintain some central definition of the routers.
Let me know if you need a gist to demonstrate the issue.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 1
- Comments: 25 (12 by maintainers)
I know this is closed but I just want to comment that this behavior should be much better documented. I just spent at least 30 minutes puzzling over why my first two verticles seemed to be randomly 404’ing and other odd behavior when both of them were near identical copies of the example code provided.
And for the record, I agree with @sfitts - being able to code up a new verticle and deploy it into a server without any modification of existing code would be a big win. To a “newbie” seems to be the general spirit and philosophy of Vert.x, and one of its attractions. For example, one reason I’m exploring Vert.x is that I want people who write code in different languages to work on the same application. Now it seems like they’re all going to have to work on code in the same language for at least this one small part. So it’s quite odd to me to find this thread with experienced people in it saying that what they like to do is lump all the routing for their Verticles together in one class, when it seems to run counter some of the things that most make me want to use Vert.x!
We do essentially what you started to gravitate towards. We have a Verticle that is responsible for deploying the HttpServer and configuring the routes. If/when we deploy multiple copies of that Verticle we ensure that all of them are configured identically. The one difference is that we configure the routes dynamically so we don’t have a centralized “here are all my routes” method/file. It would be nice if Vert.x provided a bit more support for this pattern, but it isn’t too hard to layer on top of what they do provide, so that’s what we did.
While I understand that position, it is unfortunate. To me one of the great strengths of Vertx is the ability to support dynamic loading and scaling of new Verticles and we hoped to leverage this to support the ability to expand/augment the API of our product. Need a new set of features – create a verticle that provides those and the API to access them and then load that verticle into the system. The approach you’re suggesting would require that we maintain a single, monolithic, centralized view of our REST API which runs directly counter to the modular, decentralized nature of Vertx overall.