Aias00 opened a new issue, #7743: URL: https://github.com/apache/shenyu/issues/7743
## Current behavior Independent `HeartbeatListener` runs a single periodic reporting task with a five-second target period. `sendHeartbeat` loops over the configured Admin list sequentially; token loading/login and `RegisterUtils.doHeartBeat` are synchronous network calls. Catching a failure allows the loop to continue only after that call returns or times out. A slow first Admin therefore delays reports to otherwise healthy later Admins and delays the next reporting round. An endpoint that streams an unfinished response slowly enough to avoid individual read timeouts can occupy the call well beyond the twenty-second Admin liveness threshold. Several ordinary timeout delays can also accumulate across the list. This can cause healthy destinations to observe stale/missing heartbeats even though they are reachable. ## Source evidence - [Single scheduled task and sequential send loop](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-register-center/shenyu-register-client-beat/src/main/java/org/apache/shenyu/register/client/beat/HeartbeatListener.java#L102) - [Synchronous heartbeat operation](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-register-center/shenyu-register-common/src/main/java/org/apache/shenyu/register/common/utils/RegisterUtils.java#L104) - [HTTP timeout configuration and blocking response-body read](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-register-center/shenyu-register-common/src/main/java/org/apache/shenyu/register/common/utils/OkHttpTools.java#L46) Source-confirmed serialization of work; no real multi-Admin fault test was run during issue preparation. Impact depends on the duration of the blocked operation and reporting policy. ## Acceptance criteria - [ ] Use a controlled slow/stalled first Admin and a healthy second Admin to demonstrate the reporting delay, without long sleeps. - [ ] Define an end-to-end deadline for each destination, covering login, network phases and response consumption. - [ ] Isolate destinations using bounded independent scheduling/asynchronous work or a similarly bounded design. Prevent overlapping retries and unbounded work queues. - [ ] A slow/unreachable destination does not starve reports to a healthy destination beyond the documented liveness budget. - [ ] Test token-loading stalls, slow bodies, ordinary failures, recovery and shutdown cancellation; retain per-destination token ownership. - [ ] Report cadence/deadline settings and resource bounds are documented; do not simply add an unbounded thread pool. Related: #7725 concerns reauthentication after token rejection; #6608 concerns uncaught exceptions cancelling schedules. Neither isolates long-running successful/pending calls. -- 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]
