jetstream-api 0.19.2__tar.gz → 0.19.5__tar.gz

{jetstream_api-0.19.2/jetstream_api.egg-info → jetstream_api-0.19.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: jetstream-api
-Version: 0.19.2
+Version: 0.19.5
 Summary: Python client API for iLink M.O.M. (Message Oriented Middleware)
 Author: snowjeans
 License: Boost Software License - Version 1.0 - August 17th, 2003
@@ -60,6 +60,39 @@ lz4 배치 압축을 쓰려면 `pip install "jetstream-api[lz4]"`, zstd 배치
 ## 설치 방법
 pip install jetstream-api
 
+## 0.19.5 변경 - 멱등 producer 도 FLUSH TOPIC / epoch 변경을 넘긴다 (자바 v2.15.5 와 같음, 짝 엔진 7.0.1.3512 이상)
+
+> 0.19.4 는 시험 저장소(test.pypi)에만 올렸고 배포하지 않았습니다. 0.19.4 는 앞선 시도의 결과를 모르는 배치가 이 거절을
+> 받으면 `commit in doubt` 로 올렸는데, FLUSH 순간 복제 확인을 기다리던 배치가 늘 그 경우라(엔진이 "결과 모름" 으로 답합니다)
+> FLUSH 때마다 앱에 드러났습니다(회귀 FLUSHOLDPROD-1). 아래가 고친 동작입니다.
+
+- 멱등 producer(기본)가 `MIMQE_TOPIC_FLUSHED` / `MIMQE_TOPIC_EPOCH_MISMATCH` 로 거절된 배치를 **앱에 올리지 않고**
+  메타데이터를 다시 받아 다시 보냅니다. 0.19.3 까지는 멱등이면 실패로 올렸습니다(0.7.1 절) - FLUSH 로 새로 만든 토픽은
+  처음 받은 번호를 기준선으로 삼아, 같은 번호로 다시 보낸 배치가 적재 없이 성공으로 답해질 수 있었기 때문입니다.
+  이제 번호를 다시 매겨 보내므로 그렇게 가려지지 않습니다(엔진 r3525 에서 계약 확인: 이 두 거절은 그 시도가
+  적재되지 않은 것이 확정입니다).
+- FLUSH 와 겹친 구간에서는 **파티션 안 순서가 바뀔 수 있습니다** - 거절된 배치가 이미 나가 있던 뒤 배치보다 늦게
+  적재됩니다(비멱등과 같습니다).
+- 앞선 시도의 결과를 모르는 배치(연결 끊김으로 답이 없었거나 엔진이 "결과 모름" 으로 답한 것)가 이 거절을 받으면
+  번호를 다시 매기지 않고 **같은 번호로** 다시 보냅니다. epoch 는 FLUSH 없이도 바뀌므로(데이터는 그대로) 앞선 시도가
+  적재돼 있을 수 있습니다 - 그러면 같은 번호가 중복 응답(원래 좌표)으로 끝나고, FLUSH 였다면 새 토픽이 그 번호로 적재합니다.
+- 가를 수 없는 경우 하나만 앱에 올립니다: 그 재전송에 엔진이 **좌표 없는 중복**으로 답하면
+  `MIMQE_TOPIC_EPOCH_MISMATCH (commit in doubt - ... answered duplicate without coordinates; the batch may not be stored)` 입니다.
+  이미 적재돼 있는 것인지, FLUSH 로 새로 만든 토픽에서 뒤 배치에 가려진 것인지 클라가 알 수 없습니다.
+- 재시도 예산은 그대로입니다(`retries` / `retryBackoffMs` / `deliveryTimeoutMs`).
+
+## 0.19.3 변경 - 코디네이터 이동을 기다려 넘긴다, 문서 (자바 v2.15.3 과 같음, 짝 엔진 7.0.1.3512 이상)
+
+- `addNode` / `removeNode`: 파티션 배치(PLACEMENT)를 켠 정의에서는 `replicas` 가 파티션당 복제본 수라 노드를 더해도
+  늘리지 않고, 빼도 줄이지 않습니다(뺀 뒤 브로커 수보다 크면 그 수로 내립니다). 배치가 꺼진 정의는 전과 같이 ±1 입니다.
+- `setClusterProperty`: `replicas` 가 브로커 노드 수보다 크면 `MIMQE_INVALID_PROPERTY (REPLICAS <r> exceeds <n> data nodes)`.
+- `replicas` 에 0 을 넣어 보내면 명시한 값을 지워 미설정으로 되돌립니다(`minSync` 와 같은 규칙, 빈칸 = 그대로 둠).
+- 소비 v2: 그룹 코디네이터가 `NOT_COORDINATOR`(4175) / `LOADING`(4176) 으로 답하면 쉬었다가(100ms 부터 두 배, 1초까지)
+  10초 안에서 코디네이터를 다시 찾습니다. 끝내 안 되면 `MIMQE_NOT_AVAILABLE (group coordinator for <그룹>)` 입니다.
+  0.19.2 는 쉬지 않고 20번 뒤 4175 사유(`MIMQE_NOT_COORDINATOR (this node follows)`)를 그대로 올려, 페일오버 순간
+  코디네이터 조회가 몇 초 옛 리더를 가리키는 동안 `subscribe` 가 실패할 수 있었습니다. 커밋 조회가 끝내 안 되면 시작 위치로
+  가지 않고 거절합니다.
+
 ## 0.19.2 변경 - 소비 v2(그룹 코디네이터 · 클라가 읽는 자리를 든다), 발행 다중 연결 (자바 v2.15.2 와 같음, 짝 엔진 7.0.1.3512)
 
 > 0.19.0 · 0.19.1 은 시험 저장소(test.pypi)에만 올렸고 배포하지 않았습니다 - 그 뒤 찾은 결함을 고쳐 이 판으로 냅니다:
@@ -593,7 +626,7 @@ svc.createCluster(c)
   멱등이 저절로 꺼집니다. `enableIdempotence(True)` 를 명시하고 그 둘과 함께 쓰면 전처럼 생성 때 `ValueError` 입니다.
 - 멱등이면 토픽을 비우거나(FLUSH) epoch 가 바뀐 순간 걸려 있던 배치를 다시 보내지 않고 실패로 올립니다
   (`MIMQE_TOPIC_FLUSHED` / `MIMQE_TOPIC_EPOCH_MISMATCH`). 0.7.0 기본처럼 조용히 다시 보내려면 `enableIdempotence(False)` 를
-  명시하십시오.
+  명시하십시오. **(0.19.5 부터 멱등도 조용히 다시 보냅니다 - 0.19.5 절)**
 - `batchSize` 기본값이 **16384** 입니다(파티션 배치 하나의 상한). 0.7.0 은 262144 였습니다 - 처리량이 모자라면
   `batchSize(262144)` 처럼 늘리십시오.
 - producer 수 안내: 한 토픽의 producer(연결)는 1~4개면 충분합니다(엔진 7.0.1.3407 실측).