Add endpoint connection-lifecycle hooks and a configurable establishment timeout#86
Merged
Merged
Conversation
…ent timeout Give callers more insight into and control over connection establishment: - `rmqt::Endpoint` gains `onConnectSuccess()`/`onConnectFailed()` lifecycle hooks (no-op by default) so an endpoint can observe when a connection is established, or is down and will be retried -- useful for monitoring or metrics. The hooks are invoked synchronously on the connection's event-loop thread, after the critical connection bookkeeping, and each call is wrapped so a throwing override cannot propagate into the event loop. `onConnectFailed()` fires only on retriable failures, not on terminal ones. - `RabbitContextOptions::setConnectionEstablishmentTimeout()` makes the bound on a single connection-establishment attempt configurable (the default is unchanged), so callers can tune how long a stalled attempt may run before it is retried. The timer is applied at millisecond granularity, so a sub-millisecond value is rejected (asserted, and logged) to avoid an immediate-expiry retry loop that could never establish. This is a separate option from `setConnectionErrorThreshold()`: the error threshold governs how long a *repeatedly failing* connection keeps retrying before the error is surfaced to the application, whereas the establishment timeout bounds a *single* connect-and-handshake attempt before it is aborted and retried. A caller may want a short per-attempt bound (fail fast, retry sooner) while still tolerating a long overall retry window, so the two are tuned independently. Also downgrade the hung-connection-establishment timeout log from `BALL_LOG_FATAL` to `BALL_LOG_ERROR`. Now that the establishment timeout is configurable (and can be short), an expiry is an expected, self-healing event -- the attempt is torn down and retried -- so `FATAL` over-states it. `ERROR` keeps it loud enough to show a disconnect period without implying the process is unusable. Any monitoring keyed on the previous `FATAL` severity of this message should move to `ERROR`; the `hung_connection_reset` metric is unchanged and is the severity-independent signal. Includes unit tests for the hooks and the configurable timeout.
thisisnsh
approved these changes
Jul 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Give callers more insight into and control over connection establishment:
rmqt::EndpointgainsonConnectSuccess()/onConnectFailed()lifecycle hooks (no-op by default) so an endpoint can observe when a connection is established, or is down and will be retried -- useful for monitoring or metrics. The hooks are invoked synchronously on the connection's event-loop thread, after the critical connection bookkeeping, and each call is wrapped so a throwing override cannot propagate into the event loop.onConnectFailed()fires only on retriable failures, not on terminal ones.RabbitContextOptions::setConnectionEstablishmentTimeout()makes the bound on a single connection-establishment attempt configurable (the default is unchanged), so callers can tune how long a stalled attempt may run before it is retried. The timer is applied at millisecond granularity, so a sub-millisecond value is rejected (asserted, and logged) to avoid an immediate-expiry retry loop that could never establish.This is a separate option from
setConnectionErrorThreshold(): the error threshold governs how long a repeatedly failing connection keeps retrying before the error is surfaced to the application, whereas the establishment timeout bounds a single connect-and-handshake attempt before it is aborted and retried. A caller may want a short per-attempt bound (fail fast, retry sooner) while still tolerating a long overall retry window, so the two are tuned independently.Also downgrade the hung-connection-establishment timeout log from
BALL_LOG_FATALtoBALL_LOG_ERROR. Now that the establishment timeout is configurable (and can be short), an expiry is an expected, self-healing event -- the attempt is torn down and retried -- soFATALover-states it.ERRORkeeps it loud enough to show a disconnect period without implying the process is unusable. Any monitoring keyed on the previousFATALseverity of this message should move toERROR; thehung_connection_resetmetric is unchanged and is the severity-independent signal.Includes unit tests for the hooks and the configurable timeout.