Ocelot
Ocelot copied to clipboard
When I use Consul service discovery `UpstreamHost` property isn't working
Expected Behavior / New Feature
When I use DownstreamHostAndPorts directly it works,The following two links point to different services.
article services: http://gateway.afuyy.com/test
live service: http://test.gateway.afuyy.com/test
when i use consul serviceDiscovery UpstreamHost not working,Both of the following links point to the same service.
http://consulgateway.afuyy.com/test
http://test.consulgateway.afuyy.com/test
Specifications
- Version: ocelot version: 12.0.1 .netcore version: 2.0
- Platform:
- Subsystem:
Where is your consul configuration on ocelot.json ?
example:
{
"ReRoutes": [
{
"DownstreamPathTemplate": "/api/values",
"DownstreamScheme": "http",
"UpstreamPathTemplate": "/getvalues",
"UpstreamHttpMethod": [ "Get" ],
"FileCacheOptions": { "TtlSeconds": 10 },
"AuthenticationOptions": {
"AuthenticationProviderKey": "AuthScheme",
"AllowedScopes": []
},
"ServiceName": "valueapi",
"LoadBalancerOptions": {
"Type": "LeastConnection"
}
},
{
"DownstreamPathTemplate": "/api/auth",
"DownstreamScheme": "http",
"ServiceName": "auth",
"UpstreamPathTemplate": "/api/auth",
"UpstreamHttpMethod": [ "Get" ]
}
],
"GlobalConfiguration": {
"RequestIdKey": null,
"ServiceDiscoveryProvider": {
"Host": "localhost",
"Port": 8500,
"Type": "Consul"
},
"RateLimitOptions": {
"ClientIdHeader": "ClientId",
"QuotaExceededMessage": "",
"RateLimitCounterPrefix": "",
"DisableRateLimitHeaders": false,
"HttpStatusCode": 428
},
"DownstreamScheme": "http"
}
}
on ocelot.global.json
Facing similar issue.
Same, so I came.
Use the same upstream pathtemplate That's the problem.
Hi @wtf-boy ! Yes, first scenario is correct, the second is invalid.
- usage of the same
"UpstreamPathTemplate": "/test",
is wrong but validator didn't raise the red flag because of different"UpstreamHost"
properties. - usage of the same
"DownstreamPathTemplate": "/"
could be wrong if you've registeredlive
andarticle
services in Consul config in a wrong way
I guess both article
, live
services point to one host & port pair in Consul config.
Please, double check your Consul config!
@wtf-boy Also, I guess maybe Upstream Host feature doesn't work at all for Service discovery scenario. Then a normal matching rules select the first route. But it should be checked... Yeap, #216 is quite simple.
It is hard to guess, and advice something, you have to provide the logs! Now I see a misconfiguration issue. Please, upgrade to latest version 22.0 and let us know testing results once again.
This issue will be fixed as part of my PR #1944
@sliekens Steven, I can't get it... How is this issue related to #1496 in #1944 ?!.. Does Load Balancer key uniqueness (bad now) influence to finding appropriate service instance in Consul?
If you confirm, we can reopen the issue to fix this user scenario officially... + adding more tests.
@ggnaegi FYI
@raman-m Yes, it's all related to route key collisions. The route key does not currently include UpstreamHost
, so the two routes in this issue will have the same route key.
Given the current route key format is UpstreamPathTemplate|UpstreamHttpMethod|DownstreamHostAndPorts
,
then both routes will have the route key: /test|Get,Post|
(last part empty)
My PR will fix this by extending the route key format to make them unique once again.
Does Load Balancer key uniqueness (bad now) influence to finding appropriate service instance in Consul?
@raman-m no, the route key is not used when reaching out to Consul. However, the route key is used as a cache key, to prevent repeated calls to Consul for the same route. So, repeated calls will only use cached routes, and the problem occurs when route keys from different routes collide with each other, the wrong cached route will be used.
Assigned to @sliekens :wink:
Please take care of the user scenarios of this issue in unit & acceptance tests!
You can use Theory
xUnit attribute.