yandrey321 opened a new pull request, #11885:
URL: https://github.com/apache/ozone/pull/11885

   ## What changes were proposed in this pull request?
   
   **Problem.** `HeartbeatEndpointTask.call` takes the queued container actions 
for an SCM out of `StateContext` when it
   builds a heartbeat. If SCM does not process that heartbeat, the actions are 
lost:
   - **The heartbeat fails** with an `IOException`. `putBackIncrementalReports` 
restores only command status reports and
     incremental container reports.
   - **SCM asks the datanode to re-register**, because it doesn't know the 
datanode (for example after an SCM restart) or
     because the datanode is unhealthy with an incompatible version. 
`SCMDatanodeHeartbeatDispatcher.dispatch` then
     returns a `ReregisterCommand` without firing any event for the heartbeat, 
and since the RPC succeeded, nothing is
     put back.
   
   The CLOSE action for a full container is only created again by a later write
   (`HddsDispatcher.sendCloseContainerActionIfNeeded`). If no write follows, 
the container stays OPEN in SCM until its
   pipeline closes or an administrator closes it. While it is OPEN, its delete 
transactions are skipped and
   `ReplicationManager`, the balancer and the scanner leave it alone. Pipeline 
actions are not affected: close pipeline
   actions stay queued in `StateContext.PipelineActionMap` until the pipeline 
is removed.
   
   **Change.**
   - New `StateContext.putBackContainerActions(actions, endpoint)`. It puts the 
actions back at the front of that SCM's
     queue, in their original order, and skips actions that are queued again 
already, because a write may have queued
     the same CLOSE action while the heartbeat was in flight. Nothing happens 
if the endpoint was removed meanwhile.
   - `HeartbeatEndpointTask.call` puts the heartbeat's container actions back 
when the heartbeat fails with an
     `IOException`, next to `putBackIncrementalReports`, and when the response 
contains a `reregisterCommand`.
   - The per-SCM container action queue is declared as a `Deque` instead of a 
`Queue` to allow adding at the front; it
     already was a `LinkedList`.
   
   **Key decisions.**
   - **Resending is safe.** The datanode can't tell whether SCM processed a 
heartbeat whose response was lost, so it may
     send an action twice. SCM's `CloseContainerEventHandler` only finalizes a 
container that is still OPEN, and a close
     command for a CLOSING container is deduplicated by its lease; datanodes 
already send repeated CLOSE actions today,
     one for each write past the threshold.
   - **Any reregister command triggers the put-back,** not only the 
unregistered-datanode case. SCM returns it only from
     the two branches that skip the heartbeat.
   - **Put back at the front, in the original order,** which is why the queue 
becomes a `Deque`. A heartbeat carries
     at most `hdds.container.action.max.limit` actions (default 20), so this 
only matters when more are pending, for
     example when many containers fill up while SCM is down. Then the actions 
that were not processed are the oldest,
     and they go out first with the next heartbeat. Appending them at the end 
of the queue, as the patch attached to the
     Jira does, is equally correct (nothing is lost, and everything is sent 
eventually), but it puts them behind every
     action queued meanwhile, and each failed heartbeat rotates the queue, so 
an older CLOSE action can wait a few more
     heartbeats (30 s each by default). The cost is changing the declared type 
of the queue, which already is a
     `LinkedList`.
   - **Only container actions.** Incremental container reports dropped on 
re-registration are covered by the full
     container report sent when registering. The datanode doesn't put back 
command status reports after a reregister
     either; that is unchanged here.
   
   **Related.** HDDS-17269 (heartbeat tasks queued behind a slow one) is a 
separate scheduling problem. With this
   change, the container actions drained by such a stale heartbeat are no 
longer lost when it gets a reregister reply or
   fails; the queued-task backlog itself is not addressed here.
   
   Generated-by: Claude Code (Claude Opus 5.5)
   
   ## What is the link to the Apache JIRA
   
   https://issues.apache.org/jira/browse/HDDS-17267
   
   ## How was this patch tested?
   
   Unit and integration tests.


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