Skip to content

fix: configurable cluster log-channel term length (oms#73 CI starvation)#102

Merged
emrebulutlar merged 1 commit into
mainfrom
fix/oms73-log-term-length
Jul 7, 2026
Merged

fix: configurable cluster log-channel term length (oms#73 CI starvation)#102
emrebulutlar merged 1 commit into
mainfrom
fix/oms73-log-term-length

Conversation

@emrebulutlar

Copy link
Copy Markdown
Member

Companion to openexch/oms#73 (e2e failover suite red on CI).

Mechanism

TRANSPORT_TERM_LENGTH never covered the consensus LOG channel: match never sets logChannel, so Aeron's LOG_CHANNEL_DEFAULT (aeron:udp?term-length=64m) applied. Follower catch-up replay inherits it, so every replay attempt maps and zero-faults a non-sparse 192MB (3×64m) buffer, lingering 5s on failure. On a small CI runner the election window degenerates into ReplaySession no connection established storms — the signature of both oms#73 failure modes (no new leader after kill; node0 never rejoins).

Change

  • TransportConfig.logTermLength() — env TRANSPORT_LOG_TERM_LENGTH / prop transport.log.term.length, default 64m = prod behavior unchanged.
  • AeronCluster sets consensusModuleContext().logChannel(aeron:udp?term-length=<value>) next to the other env-driven channel config.

Evidence (local, 24-core box)

  • match main, harness defaults: e2e /dev/shm peak 1443MB, 24-27 files >32M, biggest 192MB log buffers.
  • with this change + TRANSPORT_LOG_TERM_LENGTH=4m: peak 900MB, largest file 48MB (16m IPC buffers), suite PASS.

The oms harness PR (follows) sets 4m for e2e; its CI run builds match from main and is the end-to-end validation.

🤖 Generated with Claude Code

…rvation)

The consensus LOG channel was the one channel TRANSPORT_TERM_LENGTH never
reached: Aeron's LOG_CHANNEL_DEFAULT (term-length=64m) applied regardless,
and every follower catch-up replay mapped + zero-faulted a fresh non-sparse
192MB (3x64m) buffer. On small CI runners the election/rejoin window spends
whole connect-timeouts faulting buffers, surfacing as ReplaySession
'no connection established' storms and the openexch/oms#73 e2e failures
(both 'no new leader' and 'node0 never rejoins' modes).

New TRANSPORT_LOG_TERM_LENGTH / transport.log.term.length knob, default 64m
= prod behavior unchanged. The oms e2e harness sets it to 4m: verified
locally, peak e2e /dev/shm 1443MB -> 900MB, 192MB buffers gone, suite green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@emrebulutlar
emrebulutlar force-pushed the fix/oms73-log-term-length branch from 8da84f0 to e1b7056 Compare July 7, 2026 19:28
@emrebulutlar
emrebulutlar merged commit b4ac457 into main Jul 7, 2026
2 checks passed
@emrebulutlar
emrebulutlar deleted the fix/oms73-log-term-length branch July 7, 2026 19:28
emrebulutlar added a commit that referenced this pull request Jul 10, 2026
…the oms#73 fix) (#127)

Archive.Context.replicationChannel and ConsensusModule.Context.replicationChannel
both built endpoint-only URIs, so Aeron's 64m default term-length applied to
every replication/catch-up replay regardless of TRANSPORT_LOG_TERM_LENGTH.
Same starvation class as oms#73: on small hosts (CI runners) a rejoining node
maps a fresh non-sparse 3-term buffer per replay and elections time out -
match PR #102 fixed the log channel but left both replication channels on the
default. This is the root cause of the oms e2e failures (ArchiveException:
no connection established for replayChannel=...term-length=64m).

Prod behavior unchanged: logTermLength() defaults to 64m; CI sets the env knob.


Claude-Session: https://claude.ai/code/session_012ddjgSUkUdVdBtBh4b2hde

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant