Closed RainySeason673 closed 1 month ago
Dear Tang, We can't accept this short description and reproduce your problem!
Could you please provide additional details on the issue? Such as logs, configuration JSON, and the health check status of the downstream service, etc.?
Additionally, you may pose questions in the Discussions space.
This is an obvious and simple bug, and I have tried to print some logs for your reference.
downstream service status is normal, success open by Url , when i comment "ExceptionsAllowedBeforeBreaking" or "TimeoutValue",everything will be OK
downstream service status is normal, success open by Url , when i comment "ExceptionsAllowedBeforeBreaking" or "TimeoutValue",everything will be OK
try to add "DurationOfBreak": yourValue in QoS Section
@RainySeason673
when i comment "ExceptionsAllowedBeforeBreaking" or "TimeoutValue",everything will be OK
If the route works well without enabled QoS, then why are you writing us and reporting the issue? Read the docs → QoS
If you have more questions then post them to Q-&-A discussions❗
As a team, we don't see any issues with Ocelot. There is misconfiguration issue of your ocelot.json
@RaynaldM It can be a bug...
- use follow two configuration items together:
"QoSOptions": { "ExceptionsAllowedBeforeBreaking": 3, "TimeoutValue": 3000 }
So, possibly absence of DurationOfBreak
can generate an exception. But I wonder if there is no default value for DurationOfBreak
.
It seems we have to investigate this case...
downstream service status is normal, success open by Url , when i comment "ExceptionsAllowedBeforeBreaking" or "TimeoutValue",everything will be OK
try to add "DurationOfBreak": yourValue in QoS Section
actually, I have already configured this item, but the problem is not with it
@RainySeason673
when i comment "ExceptionsAllowedBeforeBreaking" or "TimeoutValue",everything will be OK
If the route works well without enabled QoS, then why are you writing us and reporting the issue? Read the docs → QoS
If you have more questions then post them to Q-&-A discussions❗
As a team, we don't see any issues with Ocelot. There is misconfiguration issue of your
ocelot.json
My configurations are all from official documents , so why do you think there is misconfiguration of my ocelot.json? and why not confirm if this issue exists?
{
"Routes": [
{
"UpstreamPathTemplate": "/profile",
"UpstreamHttpMethod": [ "Get" ], //TODO 这里配置options是否可以直接处理预检请求?如果不行还是自定义一个中间件来实现
"DownstreamPathTemplate": "/profile",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 5001
}
],
"DownstreamHeaderTransform": {
"Access-Control-Allow-Oringin": "http://localhost:8070" //允许前端地址跨域
},
// 熔断设置
"QoSOptions": {
"ExceptionsAllowedBeforeBreaking": 3, //允许多少个异常请求
"DurationOfBreak": 1000, // 熔断的时间,单位为ms
"TimeoutValue": 5000 //单位ms 如果下游请求的处理时间超过多少则自如将请求设置为超时 默认90秒
}
},
{
"UpstreamPathTemplate": "/order/swagger/v1/swagger.json",
"UpstreamHttpMethod": [ "Get" ],
"DownstreamPathTemplate": "/swagger/v1/swagger.json",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 5931
}
]
},
{
"UpstreamPathTemplate": "/user/swagger/v1/swagger.json",
"UpstreamHttpMethod": [ "Get" ],
"DownstreamPathTemplate": "/swagger/v1/swagger.json",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 5930
}
]
}
],
"GlobalConfiguration": {
"RequestIdKey": "ot-traceid"
}
}
this is my ocelot.json
Define Catch All route for /user
and /order
paths and forget about the issue:
"UpstreamPathTemplate": "/order/{catchAll}",
"DownstreamPathTemplate": "/{catchAll}",
and
"UpstreamPathTemplate": "/user/{catchAll}",
"DownstreamPathTemplate": "/{catchAll}",
Also you need define all possible HTTP verbs.
Better to define Catch All for profile
paths too:
"UpstreamPathTemplate": "/profile/{all}",
"DownstreamPathTemplate": "/profile/{all}",
Hope it helps!
Expected Behavior / New Feature
Actual Behavior / Motivation for New Feature
Steps to Reproduce the Problem
"QoSOptions": { "ExceptionsAllowedBeforeBreaking": 3, "TimeoutValue": 3000 }
Specifications