1편에서 HttpClient5 커넥션 풀이 커넥션을 빌려주고 돌려받는 흐름과, 쉬는 동안 끊긴 커넥션을 쓰지 않으려고 시각(keep-alive·evictIdleConnections·timeToLive)과 isStale() 로 거르는 설정을 봤다. 이 글은, 그럼에도 죽은 커넥션에 요청이 실리는 경우(시각 계산이 어긋나거나 isStale() 이 ...

HttpClient5 커넥션 풀이 커넥션을 언제 만들고, 언제 돌려받고, 언제 버리는지, 그리고 풀 설정이 그 과정의 어디에 걸리는지를 소스로 따라간다. 기준 버전은 httpclient5 5.4.2 / httpcore5 5.3.3 이다. HTTP 커넥션 풀이란 HTTP 커넥션 풀은 한 번 맺은 TCP 커넥션을 응답 뒤에도 닫지 않고...

토픽과 파티션은 카프카에서 가장 먼저 배우는 개념이지만, “토픽은 폴더고 파티션은 그 안의 파일”이라는 비유 수준에서 멈추기 쉽다. 실제 디스크를 열어 보면 그 비유는 맞지 않고, 그 차이를 모르면 “파티션은 왜 줄일 수 없는가”, “파티션을 늘렸더니 왜 순서가 깨지는가” 같은 질문에서 막힌다. 이 글은 토픽과 파티션의 정의부터 디스크에 실제로 어떻...

RestTemplate으로 HTTP를 호출할 때 타임아웃 설정 입구는 네 곳에 흩어져 있다 — 커넥션 매니저, HttpClient, 요청 팩토리, 요청 컨텍스트. 같은 이름의 값이 여러 곳에 걸려 있을 때 실제로 무엇이 적용되는지를 Apache HttpClient 5.5.2 / Spring Framework 6.2.19 소스와 실행 결과로 확인했...

setConnectTimeout / setReadTimeout 은 호출하는 순간엔 필드에 값을 저장할 뿐이다. 그 값이 실제로 소비되는 곳은 소켓 connect() 와 소켓 read() 두 곳이고, 커넥션 풀 클라이언트(HttpClient5)는 여기에 “풀에서 커넥션 빌리는 대기”가 하나 더 붙는다. 이 글은 그 “세팅 지점”과 “적용 지점”을 ...

특정 목적지로 향하는 TIME_WAIT 소켓이 많으면 ephemeral port가 부족해져 그 목적지로 새 요청을 못 보낼 수 있고, CLOSE_WAIT 소켓이 많으면 fd가 고갈돼 파일 처리·DB 연결·API 호출이 전부 막히는 전면 장애로 번질 수 있다고 한다. 아직 이 문제를 직접 겪어본 적은 없고 재현 실습도 하지 않았다. 다만 두 ...

외부 호출 실패 처리 설계 — 질문으로 따라가는 정리 상황: 우리 서버가 외부 서버를 호출해 사용자당 쿠폰을 딱 한 장 발행해야 한다. 그 호출에서 타임아웃이 나면 어떻게 처리할 것인가? 각 절은 실제로 던졌던 질문에서 출발한다. Q. = 던진 질문 / A. (내 답변) = 내가 낸 답 / 그 아래가 확장·정정된 내용. 출발점 — 외부...

느린 외부 호출이 만드는 장애 — 질문으로 따라가는 정리 전제 구조: Client — WAS — DB WAS에서 요청 처리 시 외부 호출이 필수인데, 그 응답이 오래 걸리는 상황 각 절은 실제로 던졌던 질문에서 출발한다. Q = 내 질문 / A(나) = 내가 낸 답 / 그 아래가 확장된 내용. Q1. 요청 처리 중 외부 호출이 느리면 ...

앞 글(ISR 1편)에서 ISR 이 무엇이고, follower 의 fetch 가 어떻게 sync 판정과 acks=all 계약으로 이어지는지까지 정리했다. 이 글은 그 위에서 커밋 경계(HW) 가 어떻게 정해지고, 리더가 바뀌는 순간 그 경계가 어떻게 무너지는가 를 다룬다. HW → 복제 라운드트립 → HW 의 한계(Leader Epoch) →...

분산 메시지 시스템에서 데이터 유실 방지 + 고가용성을 동시에 달성하려면 복제가 필수. “몇 개에 복제됐을 때 ack 할지”, “리더 죽으면 누가 새 리더?” 라는 두 결정을 Kafka 는 ISR (In-Sync Replicas) 이라는 동적 집합 으로 추상화. 정적 RF (replication factor) 와 별도로, 런타임에 실제 sync 된...