choksi2212 opened a new pull request, #7809: URL: https://github.com/apache/shenyu/pull/7809
### Describe what this PR does and why we are doing this `MemoryLimitCalculator.maxAvailable()` sampled only `Runtime.freeMemory()`, i.e. the free part of the *currently committed* heap. Queue admission built on it (`MemorySafeLinkedBlockingQueue`, which backs `MemorySafeTaskQueue`, the shared `HierarchicalWheelTimer` queue and the work queues) therefore rejected tasks whenever the committed heap held less free memory than the configured floor, even when the JVM could still commit heap up to `-Xmx`. The production-visible case from #7803: with `-Xms256m -Xmx768m` the wheel timer queue (built with the `Constants.THE_256_MB` floor) silently dropped recurring tasks such as heartbeat registrations — 156MiB free committed vs 668MiB headroom to `-Xmx`, `accepted=false`, with the default `DiscardPolicy` swallowing the rejection. ### Change `refresh()` now derives the limit from `maxMemory() - (totalMemory() - freeMemory())`: - When the committed heap already equals `-Xmx` (`-Xms == -Xmx`, the usual pinned-heap / container deployment), the value is **identical** to `freeMemory()`, so those deployments keep their exact behavior. - When the heap can still grow, admission only opens up by the amount the JVM can genuinely still commit toward `-Xmx`. Consumers that pick this up automatically: `MemorySafeLinkedBlockingQueue` (+ `MemorySafeTaskQueue`), `MemorySafeLRUMap`, and the `maxWorkQueueMemory` default in `ShenyuConfig`. The apache/dubbo twin of this class still samples `freeMemory()`; this change intentionally improves on that, so the two are no longer byte-equivalent here. ### Tests - New `MemorySafeLinkedBlockingQueueTest.testAdmissionCountsMemoryTheHeapCanStillCommit`: on a growable heap, a floor between the free committed memory and the `-Xmx` headroom must admit. Verified to fail on the previous behavior. - New `MemoryLimitCalculatorTest.testMaxAvailableCountsMemoryTheHeapCanStillCommit`: `maxAvailable()` must cover the part of the heap the JVM can still commit. - The existing tests that used `Integer.MAX_VALUE` as a "guaranteed rejection" floor now use a `maxMemory() + 1` floor guarded by `assumeTrue`: the old floor could never force rejection once the headroom is counted on heaps above 2GiB, and was already environment-dependent before. They pass unchanged on the previous behavior. - `shenyu-common` module suite: **509 tests, 0 failures**; the memory classes additionally verified under `-Xms64m -Xmx256m` (growable heap, all assumption-guarded tests execute). `checkstyle:check` passes. Fixes #7803 Make sure that: - [x] You have read the [contribution guidelines](https://shenyu.apache.org/community/contributor-guide). - [x] You submit test cases (unit or integration tests) that back your changes. - [x] Your local test passed `./mvnw clean install -Dmaven.javadoc.skip=true`. (Ran `./mvnw -pl shenyu-common -am test` for the affected module: 509 tests, 0 failures, plus `checkstyle:check`; the change is confined to `shenyu-common`.) -- 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]
