Aias00 opened a new issue, #7463: URL: https://github.com/apache/shenyu/issues/7463
## Description The eager-growth policy in TaskQueue.default offer is never called by the two production task queue implementations under normal admission. MemorySafeTaskQueue and MemoryLimitedTaskQueue inherit concrete offer methods from their superclass queues. Java class methods take precedence over interface defaults. ShenyuThreadPoolExecutor therefore enqueues a second task rather than invoking the policy that returns false while pool size is below maximum, so it does not create the available additional worker. ## Reproduction Actual executor, core size 1, maximum size 2, first task blocked on a latch, and sufficient queue memory: ```text production queue: poolSize=1, max=2, queued=1, secondStarted=false explicit default-policy control: poolSize=2, max=2, queued=0, secondStarted=true ``` The control differs only by explicitly delegating offer to TaskQueue.super.offer. Independent verification reproduced the same behavior for both MemoryLimitedTaskQueue and MemorySafeTaskQueue. No latency benchmark is needed to establish this dispatch-policy difference. ## Location - [TaskQueue.java:45](https://github.com/apache/shenyu/blob/a89b6a2338c24e978428b731e8f1edce86022418/shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/TaskQueue.java#L45): intended eager policy. - [MemoryLimitedTaskQueue.java:29](https://github.com/apache/shenyu/blob/a89b6a2338c24e978428b731e8f1edce86022418/shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/MemoryLimitedTaskQueue.java#L29): inherited offer shadows policy. - [MemorySafeTaskQueue.java:29](https://github.com/apache/shenyu/blob/a89b6a2338c24e978428b731e8f1edce86022418/shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/MemorySafeTaskQueue.java#L29): same method-resolution issue. - [ShenyuThreadPoolConfiguration.java:106](https://github.com/apache/shenyu/blob/a89b6a2338c24e978428b731e8f1edce86022418/shenyu-web/src/main/java/org/apache/shenyu/web/configuration/ShenyuThreadPoolConfiguration.java#L106): shared gateway pool uses these task queues. ## Impact Severity: Medium. Confidence: high. Busy workers can leave work queued while the configured maximum still permits additional workers, defeating the documented eager pool behavior and increasing queued-request latency under load. ## Suggested Fix And Tests Explicitly override offer(Runnable) in both task queue classes and delegate to TaskQueue.super.offer, retaining doOffer for physical enqueue. Verify core/max growth, idle-worker reuse, maximum saturation, memory rejection and shutdown/retry behavior. ## Validation And Deduplication Reviewed apache/shenyu master a89b6a2338c24e978428b731e8f1edce86022418. Current classes and real executor were compiled/run; first/second worker latches and executor termination were asserted. An isolated reviewer also verified both queue classes. #6667 concerned an unbounded default maximumPoolSize, not this shadowed method. A finite maximum alone cannot activate a default method that dispatch never reaches. No matching issue or pending PR was found. ## Reviewed Revision And Validation Apache ShenYu 2.7.2-SNAPSHOT, master at a89b6a2338c24e978428b731e8f1edce86022418. Severity: medium. Confidence: high. Real core=1/max=2 executor and explicit-default-policy controls were run; isolated review also checked both queue implementations. No implementation fix or full deployed end-to-end validation was performed by this review. Source-flow and runtime evidence are distinguished above. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
