Files
document-haness/docs/clean-architecture-backend-template/tech-log-studio/transport-and-provider-semantics/case/case-messaging-kafka-f02.md
T
DongHyeonkaandClaude Fable 5.1 b25357c48a docs(clean-architecture-backend-template): fold analysis into final and re-select one topic
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다
- 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5
  (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를
  techviz 로 만들었다
- 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs
  돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다.
  Concept 이 인용한 코드가 SSOT 에 없어 뺐다
- candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-07 12:39:20 +09:00

4.8 KiB

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module, priority
kind slug title topic project status sourceRevision rootTreeNode evidenceCapturedOn assets evidence source module priority
CASE messaging-kafka-f02 천장에 닿아 일시정지된 파티션을 재개하는 경로가 없다 transport-and-provider-semantics clean-architecture-backend-template 게시 전 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 case:messaging-kafka-f02 2026-09-01
key file
messaging-kafka-f02 ../../../final/evidence/rendered/messaging-kafka-f02.svg
key file
messaging-kafka-f02-diagram ../../../final/assets/diagrams/messaging-kafka-f02.svg
../../../final/evidence/raw/messaging-kafka-f02.txt
원본 분석 절은 final/document.md#a19-messaging-kafka#L265 이다.
messaging-kafka P2

천장에 닿아 일시정지된 파티션을 재개하는 경로가 없다

pollOnce 의 파티션 루프는 세 경우에 그 파티션을 멈춘다. 이 세 경로 중 어느 것도 retries.pauseUntil(...) 을 부르지 않는다.

문제

pollOnce 의 파티션 루프는 세 경우에 그 파티션을 멈춘다.

이 세 경로 중 어느 것도 retries.pauseUntil(...) 을 부르지 않는다.

결론

그런데 폴 루프가 파티션을 재개하는 곳은 하나뿐이다.

retries 에 항목을 넣는 곳은 QueuedSettlement.enqueueRequeue 하나이고, 그것은 핸들러 실패·타임아웃·명시적 requeue 경로다.

천장·배수·풀 거부 경로는 등록하지 않는다.

따라서 천장 때문에 멈춘 파티션은 폴 루프가 스스로 재개하지 않는다.

재개할 수 있는 것은 외부에서 부른 resume(scope) 이나 재조정뿐이다.

maxInFlightPerOrderingUnit 의 기본값은 1 이다(DestinationSettings.Consumer).

한 폴이 같은 파티션의 레코드를 둘 이상 돌려주는 순간 두 번째에서 tryAcquire 가 거짓이 되고, 그 파티션이 멈춘다.

그 뒤 작업자가 끝나 coordinator.release 로 슬롯이 비어도 consumer 는 여전히 일시정지 상태다.

검증 환경

OpenJDK : 21.0.12 java -version 으로 확인 Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인 확인 방식 : QueuedSettlement 참조 3건 검색과 파티션을 멈추는 세 경로의 재개 등록 여부 확인 소스 수정 : x

재현 조건

원문은 final/document.md#a19-messaging-kafka#L265 에 있다.

본문

pollOnce 의 파티션 루프는 세 경우에 그 파티션을 멈춘다 — 천장(tryAcquire 실패), 배수 시작(tryBeginWork 실패), 풀 거부(dispatch 실패). 이 세 경로 중 어느 것도 retries.pauseUntil(...) 을 부르지 않는다.

재개가 끊긴 자리

:::evidence key="messaging-kafka-f02-diagram" alt="핸들러 실패와 타임아웃과 requeue 만 재개 목록에 등록되는 경로 안에 놓이고 천장 도달과 배수 및 풀 거부가 바깥에 빗금으로 놓인다" caption="재개가 끊긴 자리" zoom="false" :::

폴 루프가 파티션을 재개하는 곳은 applyDueResumes 하나이고 그것은 retries.dueForResume(now) 만 본다. retries 에 항목을 넣는 곳은 QueuedSettlement.enqueueRequeue 하나이고, 그것은 핸들러 실패·타임아웃·명시적 requeue 경로다.

QueuedSettlement 참조 위치

:::evidence key="messaging-kafka-f02" alt="코드베이스에서 QueuedSettlement 를 검색한 출력 3줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="QueuedSettlement 코드베이스 검색 — 3줄 · exit 0" zoom="true" :::

기본값이 이 경로를 흔하게 만든다

maxInFlightPerOrderingUnit 의 기본값은 1 이다(DestinationSettings.Consumer). 한 폴이 같은 파티션의 레코드를 둘 이상 돌려주는 순간 두 번째에서 tryAcquire 가 거짓이 되고 그 파티션이 멈춘다. 그 뒤 작업자가 끝나 coordinator.release 로 슬롯이 비어도 consumer 는 여전히 일시정지 상태다.

두 pause 가 구분되어 쓰인다

applySettlementsPAUSE_AND_SEEKcoordinator.pause(...)consumer.pause(...) 를 둘 다 부르고, 천장 경로는 consumer 쪽만 부른다. 그래서 조정자는 그 파티션을 멈춘 것으로 알지 못하고, tryAcquire 는 계속 참을 답하는데 브로커에서 레코드가 오지 않는다.

수정

천장 경로가 retries.pauseUntil(partition, seekBackTo, Duration.ZERO, now) 를 등록하면 다음 주기의 applyDueResumes 가 즉시 재개한다 — 지연이 0 이므로 dueForResume 이 곧바로 돌려준다. 배수 경로는 재개하지 않는 것이 맞고, 풀 거부 경로는 천장과 같다. 소비 경로가 조립되지 않으므로(§12.1) P2.

확인하지 못한 것

실행으로 재현하지 않았다. resume 호출처가 둘뿐이고 천장 경로가 재개 목록에 아무것도 등록하지 않는다는 것으로 판정했다.