DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
101 lines
6.0 KiB
Markdown
101 lines
6.0 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: messaging-inbox-jdbc-postgresql-f01
|
|
title: bounded purge가 구현돼 있고 호출되지 않아, cleanup이 스스로 막겠다고 한 장애를 일으킨다
|
|
topic: runtime-reachability-and-composition
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:messaging-inbox-jdbc-postgresql-f01
|
|
evidenceCapturedOn: 2026-09-01
|
|
assets:
|
|
- key: messaging-inbox-jdbc-postgresql-f01
|
|
file: ../../../final/evidence/rendered/messaging-inbox-jdbc-postgresql-f01.svg
|
|
- key: messaging-inbox-jdbc-postgresql-f01-diagram
|
|
file: ../../../final/assets/diagrams/messaging-inbox-jdbc-postgresql-f01.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/messaging-inbox-jdbc-postgresql-f01.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/messaging/messaging-inbox-jdbc-postgresql.md#L647 이다.
|
|
module: messaging-inbox-jdbc-postgresql
|
|
priority: P1
|
|
---
|
|
|
|
# bounded purge가 구현돼 있고 호출되지 않아, cleanup이 스스로 막겠다고 한 장애를 일으킨다
|
|
|
|
InboxRepository·OutboxRepository 둘 다 purge*Before(Instant, int) 오버로드를 선언하고, JdbcInboxRepository:141·JdbcOutboxRepository:486이 LIMIT + FOR UPDATE SKIP LOCKED로 구현한다. 저장소 전체에서 그 시그니처가 등장하는 9곳은 선언 2 + 구현 2 + 테스트 fake override 5이고 호출 지점이 0이다.
|
|
|
|
## 관계
|
|
|
|
- **컬럼 폭은 애플리케이션 검증과 짝을 이룬다**
|
|
같은 분석 리프에서 끌어낸 규칙이다.
|
|
- **같은 안전 규칙은 한 공식과 한 강제 시점을 갖는다**
|
|
같은 분석 리프에서 끌어낸 규칙이다.
|
|
|
|
## 문제
|
|
|
|
InboxRepository·OutboxRepository 둘 다 purge*Before(Instant, int) 오버로드를 선언하고, JdbcInboxRepository:141·JdbcOutboxRepository:486이 LIMIT + FOR UPDATE SKIP LOCKED로 구현한다.
|
|
|
|
저장소 전체에서 그 시그니처가 등장하는 9곳은 선언 2 + 구현 2 + 테스트 fake override 5이고 호출 지점이 0이다.
|
|
|
|
## 결론
|
|
|
|
InboxCleanupJob:56과 OutboxCleanupJob:50이 무제한 오버로드를 부른다.
|
|
|
|
InboxCleanupJob.DEFAULT_BATCH_SIZE = 1_000은 자기 선언 한 줄만 존재한다.
|
|
|
|
InboxCleanupJob의 javadoc이 스스로 적는다 — "A single unbounded DELETE over a table that has been accumulating for weeks holds locks long enough to block the very reservations the inbox exists to serve, so the cleanup would cause the outage it is meant to prevent." 실행되는 코드가 정확히 그 문장이 서술하는 동작이다.
|
|
|
|
OutboxRepository의 bounded 오버로드 javadoc은 한 발 더 나간다 — "The cleanup jobs describe themselves as bounded by batch size; this is the parameter that makes that true." 그 파라미터를 아무도 넘기지 않는다.
|
|
|
|
그리고 두 leaf가 동일한 형태로 그렇다.
|
|
|
|
왜 P1인가.
|
|
|
|
두 leaf 다 runtime_memberships: ["app-bootstrap"]이고 두 cleanup job이 starter에서 bean으로 만들어진다(MessagingReliabilityAutoConfiguration의 inboxCleanupJob·outboxCleanupJob). 즉 출하 구성에서 실행되는 경로이며, 백로그가 쌓인 뒤 첫 스윕에서 발현한다. 다른 미배선 발견들과 성격이 다르다.
|
|
|
|
## 검증 환경
|
|
|
|
OpenJDK : 21.0.12 java -version 으로 확인
|
|
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
|
확인 방식 : InboxRepository 참조 20건 검색으로 bounded 시그니처가 등장하는 9곳을 선언·구현·호출로 분류
|
|
소스 수정 : x
|
|
|
|
## 재현 조건
|
|
|
|
원문은 analysis/messaging/messaging-inbox-jdbc-postgresql.md#L647 에 있다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
`InboxRepository`·`OutboxRepository` 둘 다 `purge*Before(Instant, int)` 오버로드를 선언하고, `JdbcInboxRepository:141`·`JdbcOutboxRepository:486`이 `LIMIT` + `FOR UPDATE SKIP LOCKED`로 구현한다. 저장소 전체에서 그 시그니처가 등장하는 9곳은 **선언 2 + 구현 2 + 테스트 fake override 5**이고 **호출 지점이 0**이다. `InboxCleanupJob:56`과 `OutboxCleanupJob:50`이 무제한 오버로드를 부른다.
|
|
|
|
## 정리가 일으키는 장애
|
|
|
|
:::evidence key="messaging-inbox-jdbc-postgresql-f01-diagram" alt="쌓인 백로그가 무제한 DELETE 와 락 장기 보유를 지나 예약이 막히는 결과로 이어진다" caption="정리가 일으키는 장애" zoom="false"
|
|
:::
|
|
|
|
## InboxRepository 참조 위치
|
|
|
|
:::evidence key="messaging-inbox-jdbc-postgresql-f01" alt="코드베이스에서 InboxRepository 를 검색한 출력 20줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="InboxRepository 코드베이스 검색 — 20줄 · exit 0" zoom="true"
|
|
:::
|
|
|
|
## javadoc 자신이 이 동작을 서술한다
|
|
|
|
`InboxCleanupJob`의 javadoc — "A single unbounded DELETE over a table that has been accumulating for weeks holds locks long enough to block the very reservations the inbox exists to serve, so the cleanup would cause the outage it is meant to prevent." 실행되는 코드가 정확히 그 문장이 서술하는 동작이다. `OutboxRepository`의 bounded 오버로드 javadoc은 한 발 더 나간다 — "The cleanup jobs describe themselves as bounded by batch size; **this is the parameter that makes that true**." 그 파라미터를 아무도 넘기지 않는다. `InboxCleanupJob.DEFAULT_BATCH_SIZE = 1_000`은 자기 선언 한 줄만 존재한다.
|
|
|
|
## 왜 P1인가
|
|
|
|
두 leaf 다 `runtime_memberships: ["app-bootstrap"]`이고 두 cleanup job이 starter에서 bean으로 만들어진다(`MessagingReliabilityAutoConfiguration`의 `inboxCleanupJob`·`outboxCleanupJob`). 즉 **출하 구성에서 실행되는 경로**이며, 백로그가 쌓인 뒤 첫 스윕에서 발현한다. 다른 미배선 발견들과 성격이 다르다.
|
|
|
|
## 후보
|
|
|
|
두 job이 bounded 오버로드에 배치 크기를 넘기게 한다 — `InboxCleanupJob`은 이미 `DEFAULT_BATCH_SIZE`를 갖고 있다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
무제한 DELETE 가 실제 규모의 테이블에서 얼마나 오래 락을 잡는지 측정하지 않았다.
|
|
|
|
<!-- body:end -->
|