[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

XceiverServerDomainSocket.run increments the xceiver count right after accept() and compares it with maxXceiverCount. The only decrement is in closePeer, which the Receiver of an accepted connection calls when it ends. When the limit check fails, the IOException branch closes the peer but does not decrement, so a connection rejected at the limit keeps its unit of the count. The same holds for every other exit between the increment and daemon.start(): an IOException from setting the peer timeouts or from Receiver.create, an OutOfMemoryError from starting the thread, and the generic Throwable branch. Each such exit leaves the count one higher than the open connections for the life of the server, so it accepts fewer than maxXceiverCount afterwards.

This change sets a flag right after the increment and clears it once daemon.start() has handed the connection to its Receiver, which releases the unit in closePeer as before. A finally on the loop body decrements the count when the flag is still set, so every exit between the increment and the hand off releases the unit exactly once. The limit itself is enforced as before. A @VisibleForTesting getter exposes the count for the test.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-17437

How was this patch tested?

• TestXceiverServerDomainSocket.testMaxXceiverCount now closes every connection after the rejection, waits until the server's Receiver threads have ended and asserts that getXceiverCount() is 0. Without the change it fails with expected: 0 but was: 1. Only the limit rejection is exercised; the other exits are covered by code reading.
• TestXceiverServerDomainSocket (14 tests) and TestLocalChunkInputStream pass locally on macOS with libhadoop; checkstyle is clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[jojochuang]

lgtm