Why flow rule with concurrency (thread count) metric type does not support queueing?
Open
area/flow-control
kind/question
- Dominant language
- Java
- Stars
- 23.1k
- Forks
- 8.1k
- PR merge metrics
- No merged PRs in 30d
Description
先说下的场景:
我们是多租户的Web系统,由Tomcat提供HTTP服务,但HTTP连接数有限。
不想因为单租户的阻塞导致Tomcat连接被占满影响所有租户,又不想单租户线程满时立马报错,而是能够做几秒钟的排队。
看下了文档并发线程控制职能设置直接拒绝策略,而不支持像匀速器这样的排队策略,请问不支持是出于什么考虑?或者我这种场景有没有更好解决建议?
Contributor guide
Research direction
Start with Sentinel's concurrency flow-control documentation and the implementation of its concurrency metric type and rejection behavior. Determine whether queued handling is intended to be supported, then document the design rationale or an applicable approach for the multi-tenant Tomcat scenario.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100