Session 로그 fan-out에서 mutex 보유 상태의 blocking send 제거

[leehyowon14]

요약

로그 publisher는 subsMu를 보유한 상태로 subscriber 채널에 blocking send합니다. buffer가 가득 차면 publisher가 mutex를 가진 채 멈추고, timeout으로 반환하려는 Execute의 deferred unsubscribe가 같은 mutex를 기다려 교착될 수 있습니다.

• 검토 기준: main@4e87765f95c106edb3c956cfad2abc1db64c0c39
• 판정: blocking 구조 CONFIRMED, 실제 timeout 교착 CONDITIONAL/비결정적
• 우선순위: P2

영향

고출력 명령이 timeout에 도달해도 Execute가 반환하지 않고 이후 서버/CLI 종료도 지연될 수 있습니다.

발생 조건 및 확인 범위

• subscriber buffer가 가득 찰 정도의 고출력
• 소비가 중단되는 timeout 반환 시점과 publisher send가 교차
• 특정 scheduler interleaving

직접 slow subscriber를 4096/4096으로 채우면 unsubscribe가 mutex 대기로 막히는 것을 확인했습니다. 실제 Execute에서는 2,000,000줄, 20ms timeout, GOMAXPROCS=1 조건에서 13회 중 1회 750ms 이상 반환하지 않았고 stack에 mutex lock과 channel send 대기가 나타났습니다. 일반 출력에서는 항상 발생하지 않습니다.

재현 및 검증 방법

1. 내부 package 테스트에서 소비하지 않는 subscriber를 생성합니다.
2. buffer보다 많은 로그를 publish합니다.
3. 별도 goroutine에서 unsubscribe를 호출합니다.
4. 현재 제한 시간 안에 반환하지 않는지 확인합니다.
5. 실제 Execute helper는 2,000,000줄과 20ms timeout으로 -count=20, GOMAXPROCS=1 반복합니다.

기대 동작

publisher는 subsMu를 보유한 채 blocking operation을 수행하지 않아야 합니다. 느린 subscriber가 unsubscribe, 다른 subscriber 또는 프로세스 종료를 막지 않아야 합니다.

완료 조건

• mutex 보호 구간에서 blocking channel send를 제거한다.
• 느린 subscriber의 drop/bounded queue/backpressure 정책을 명시한다.
• unsubscribe와 close에서 send-on-closed panic이나 race가 없다.
• 가득 찬 subscriber가 있어도 unsubscribe가 제한 시간 내 반환한다.
• 고출력 timeout 반복 테스트에서 Execute가 안정적으로 반환한다.
• 관련 테스트를 -race로 반복한다.

관련 코드

• publish
• Execute
• subscribe