CuriousLinYu opened a new pull request, #8205:
URL: https://github.com/apache/incubator-seata/pull/8205

   <!-- Please ensure you have done the following steps: -->
   <!-- 1. Sign the CLA: https://cla-assistant.io/apache/incubator-seata -->
   <!-- 2. Verify the change is covered by tests -->
   
   Fixes #6041
   
   ## Problem
   
   `MergedSendRunnable` polls every 1ms (`MAX_MERGE_SEND_MILLS = 1`) even when 
all baskets are empty. With no traffic, the thread wakes up 1000 times per 
second, each cycle acquiring `mergeLock`, iterating `basketMap` and going back 
to sleep. This was measured at ~30% CPU per thread by Arthas in issue #6041, 
and still reproduces on 2.x (the RM client enables batch send by default: 
`DEFAULT_ENABLE_RM_CLIENT_BATCH_SEND_REQUEST = true`).
   
   ## Solution
   
   Event-driven wake-up with a preserved 1ms merge window:
   
   1. When `basketMap` is empty, the merge thread parks on 
`mergeCondition.await()` (no timeout) instead of a 1ms timed wait.
   2. Producers (`sendSyncRequest`) already `offer()` to the basket and then 
`signalAll()` when `!isSending` — this wake-up path is unchanged.
   3. After being woken, the thread keeps the original 
`await(MAX_MERGE_SEND_MILLS)` as the merge window, so messages arriving within 
1ms are still batched into a single request exactly as before.
   
   ### Race safety
   
   - The check-and-wait is atomic: `isBasketEmpty()` is evaluated and `await()` 
is entered while holding `mergeLock`.
   - Producers offer to the basket *before* acquiring `mergeLock` and 
signalling (unchanged code), so a message can never sit in the basket with the 
merge thread parked indefinitely: either the producer's signal wakes the parked 
thread, or the producer sees `isSending == true` and the thread is already in 
the send loop which drains the basket on the next iteration.
   - No behavioral change when traffic is present: the 1ms merge window and the 
send body (`basketMap.forEach`) are untouched.
   
   ## Tests
   
   - Added `testMergedSendRunnableIdleWaitState`: asserts the 
`rpcMergeMessageSend` thread is NOT in `TIMED_WAITING` after 300ms idle, then 
submits a request and verifies the basket is drained.
   - Full `NettyRemotingClientBehaviorTest`: 69 tests, 0 failures.
   
   ```
   Tests run: 69, Failures: 0, Errors: 0, Skipped: 0
   ```


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to