Aias00 opened a new issue, #7462: URL: https://github.com/apache/shenyu/issues/7462
## Description MemoryLimiter can leave eligible producers parked after its available budget changes. setMemoryLimit only assigns a value without signaling waiters. reset tests the old sum returned by sumThenReset, so clearing after shrinking the budget can reset memory to zero without notifying producers. ## Reproduction Current-source queue/limiter harness, deterministic Instrumentation size, and condition-stack synchronization: ```text increase limit: limit=61, reserved=20, producerStillBlocked=true increase control: normal dequeue woke producer=true clear after shrink: queueSize=0, reserved=0, producerStillBlocked=true ``` First case: reserve 20 bytes in a 21-byte queue; a second 20-byte put waits. Increase the limit to 61. The put remains blocked until an ordinary dequeue generates a signal. Second case: reserve 40 bytes under limit 61, shrink to 21, start a waiting 20-byte put, then clear. Its memory requirement now fits the zero-used budget, but reset does not signal because the old sum (40) was not below 21. ## Location - [MemoryLimiter.java:65](https://github.com/apache/shenyu/blob/a89b6a2338c24e978428b731e8f1edce86022418/shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/MemoryLimiter.java#L65): setter does not synchronize/notify blocked producers. - [MemoryLimiter.java:332](https://github.com/apache/shenyu/blob/a89b6a2338c24e978428b731e8f1edce86022418/shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/MemoryLimiter.java#L332): reset decides notification from the pre-reset sum. ## Expected Behavior And Impact Increasing available capacity or clearing reservations should wake producers whose requests now fit. Severity: Medium. Confidence: high. Legal live-budget changes can leave a producer indefinitely waiting despite sufficient capacity, until unrelated queue traffic or interruption occurs. ## Suggested Fix And Tests Perform budget changes under the admission lock, decide capacity from the updated state, and notify waiting producers appropriately. After reset, notify based on the zero-used state, with signalAll where multiple requests may be eligible. Test increasing a limit with a blocked put; shrink below current usage, clear and verify the put completes; cover multiple eligible producers and normal release controls. Ensure visibility of live budget changes. ## Validation And Deduplication Reviewed apache/shenyu master a89b6a2338c24e978428b731e8f1edce86022418. Leader and independent reviewer compiled actual current code and reproduced both cases using javac-only harnesses; worker cleanup was verified. Closed #3318 addressed a stale local sum in acquireInterruptibly after a release notification. This finding is the absence/wrong condition of notification for setter/reset, not that old sum-loop bug. No matching issue or PR was found. ## Reviewed Revision And Validation Apache ShenYu 2.7.2-SNAPSHOT, master at a89b6a2338c24e978428b731e8f1edce86022418. Severity: medium. Confidence: high. Leader and isolated verifier ran budget increase/shrink/reset waiter assertions with exact condition-stack synchronization. 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]
