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>
96 lines
5.3 KiB
Markdown
96 lines
5.3 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: messaging-outbox-jdbc-postgresql-f01
|
|
title: 정리 작업이 무제한 DELETE 를 쏘고, 그것을 막는 오버로드는 호출되지 않는다
|
|
topic: runtime-reachability-and-composition
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:messaging-outbox-jdbc-postgresql-f01
|
|
evidenceCapturedOn: 2026-09-01
|
|
assets:
|
|
- key: messaging-outbox-jdbc-postgresql-f01
|
|
file: ../../../final/evidence/rendered/messaging-outbox-jdbc-postgresql-f01.svg
|
|
- key: messaging-outbox-jdbc-postgresql-f01-diagram
|
|
file: ../../../final/assets/diagrams/messaging-outbox-jdbc-postgresql-f01.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/messaging-outbox-jdbc-postgresql-f01.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/messaging/messaging-outbox-jdbc-postgresql.md#L876 이다.
|
|
module: messaging-outbox-jdbc-postgresql
|
|
priority: P1
|
|
---
|
|
|
|
# 정리 작업이 무제한 DELETE 를 쏘고, 그것을 막는 오버로드는 호출되지 않는다
|
|
|
|
OutboxCleanupJob:50 과 InboxCleanupJob:56 이 무제한 오버로드를 부른다. bounded 오버로드(purgePublishedBefore(Instant, int) / purgeProcessedBefore(Instant, int))는 두 포트에 선언되고 두 구현에 구현되어 있으며 호출부가 0건이다(EVD-294, EVD-311).
|
|
|
|
## 문제
|
|
|
|
OutboxCleanupJob:50 과 InboxCleanupJob:56 이 무제한 오버로드를 부른다.
|
|
|
|
bounded 오버로드(purgePublishedBefore(Instant, int) / purgeProcessedBefore(Instant, int))는 두 포트에 선언되고 두 구현에 구현되어 있으며 호출부가 0건이다(EVD-294, EVD-311).
|
|
|
|
## 결론
|
|
|
|
두 잡 모두 starter 빈이지만 스케줄러는 등록되지 않으며, 그것은 의도된 설계다(EVD-316).
|
|
|
|
즉 기본 배포에서는 아무 일도 일어나지 않고, 애플리케이션이 문서 지시대로 잡을 스케줄하는 순간 무제한 DELETE 가 발동한다.
|
|
|
|
잠재 결함이지 상시 결함이 아니다.
|
|
|
|
bounded 구현의 주석이 결과를 명시한다: "An unbounded DELETE holds locks and writes WAL in proportion to the whole backlog, which stalls the relay and the business writes behind retention." 3일치 백로그가 쌓인 테이블에서 이것은 릴레이 정지와 비즈니스 쓰기 정체를 뜻한다.
|
|
|
|
두 리프 모두 runtime_memberships: ["app-bootstrap"] 이고 두 잡 모두 starter 빈이다.
|
|
|
|
수정은 한 줄이다 — purgePublishedBefore(cutoff, batchLimit).
|
|
|
|
maxBatches 가 그제서야 의미를 갖는다.
|
|
|
|
배치 크기는 새 파라미터가 필요하고, OutboxProperties.batchSize(100)를 재사용하거나 별도 값을 둔다.
|
|
|
|
## 검증 환경
|
|
|
|
OpenJDK : 21.0.12 java -version 으로 확인
|
|
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
|
확인 방식 : OutboxProperties 참조 28건 검색과 두 오버로드의 SQL·호출자·starter 배선 대조
|
|
소스 수정 : x
|
|
|
|
## 재현 조건
|
|
|
|
원문은 analysis/messaging/messaging-outbox-jdbc-postgresql.md#L876 에 있다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
`OutboxCleanupJob:50` 과 `InboxCleanupJob:56` 이 무제한 오버로드를 부른다. bounded 오버로드(`purgePublishedBefore(Instant, int)` / `purgeProcessedBefore(Instant, int)`)는 두 포트에 선언되고 두 구현에 구현되어 있으며 호출부가 **0건**이다(`EVD-294`, `EVD-311`).
|
|
|
|
## 두 형태의 락 구간
|
|
|
|
:::evidence key="messaging-outbox-jdbc-postgresql-f01-diagram" alt="호출되는 오버로드 쪽에 무제한 DELETE 와 전체 백로그 락이 빗금으로 놓이고 호출되지 않는 오버로드 쪽에 LIMIT 배치와 배치 단위 락이 놓인다" caption="두 형태의 락 구간" zoom="false"
|
|
:::
|
|
|
|
## OutboxProperties 참조 위치
|
|
|
|
:::evidence key="messaging-outbox-jdbc-postgresql-f01" alt="코드베이스에서 OutboxProperties 를 검색한 출력 28줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="OutboxProperties 코드베이스 검색 — 28줄 · exit 0" zoom="true"
|
|
:::
|
|
|
|
## 잠재 결함이지 상시 결함이 아니다
|
|
|
|
두 잡 모두 starter 빈이지만 스케줄러는 등록되지 않으며, 그것은 의도된 설계다(`EVD-316`). 즉 기본 배포에서는 아무 일도 일어나지 않고, 애플리케이션이 문서 지시대로 잡을 스케줄하는 순간 무제한 DELETE 가 발동한다.
|
|
|
|
## bounded 구현의 주석이 결과를 명시한다
|
|
|
|
"An unbounded DELETE holds locks and writes WAL in proportion to the whole backlog, which stalls the relay and the business writes behind retention." 3일치 백로그가 쌓인 테이블에서 이것은 릴레이 정지와 비즈니스 쓰기 정체를 뜻한다. 두 리프 모두 `runtime_memberships: ["app-bootstrap"]` 이다.
|
|
|
|
## 수정은 한 줄이고 대역도 함께 고쳐야 한다
|
|
|
|
`purgePublishedBefore(cutoff, batchLimit)` 로 바꾸면 `maxBatches` 가 그제서야 의미를 갖는다. 배치 크기는 `OutboxProperties.batchSize`(100)를 재사용하거나 별도 값을 둔다. 그리고 회귀 테스트가 성립하려면 `RecordingRepository` 를 고쳐야 한다 — 현재 대역의 bounded 구현은 `Math.min(unbounded(), limit)` 로 전부 지우고 숫자만 깎는다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
백로그가 쌓인 실제 테이블에서 무제한 DELETE 의 락 보유 시간을 측정하지 않았다. 두 SQL 과 호출부 부재로 도출했다.
|
|
|
|
<!-- body:end -->
|