jetstream-api 0.6.11__tar.gz → 0.7.0__tar.gz

{jetstream_api-0.6.11 → jetstream_api-0.7.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: jetstream-api
-Version: 0.6.11
+Version: 0.7.0
 Summary: Python client API for iLink M.O.M. (Message Oriented Middleware)
 Author: snowjeans
 License: Boost Software License - Version 1.0 - August 17th, 2003
@@ -54,6 +54,43 @@ Python으로 작성된 ILink 클라이언트 API입니다.
 ## 설치 방법
 pip install jetstream-api
 
+## 0.7.0 변경 - 발행 v2: producer 하나 = 토픽 하나, 파티션별 배치, 봉투 겹쳐 보내기 (엔진 v2 필요)
+
+발행 경로를 엔진의 새 발행 형식(v2)으로 바꿨습니다. **엔진도 v2 판이어야 합니다** - 옛 엔진에는 발행이 되지 않고
+(`MIMQE_NOT_SUPPORTED`), 옛 클라이언트(0.6.x)는 v2 엔진에 발행할 수 없습니다. 둘을 함께 올리십시오.
+
+- **producer 하나 = 토픽 하나 = 연결 하나.** `qmgr.create_producer("ORDER.EVENT", config)` 로 만듭니다. 생성할 때 토픽의
+  파티션 수를 받아 두므로 없는 토픽이면 생성 단계에서 `MIMQE_OBJECT_NOT_FOUND` 로 실패합니다. 토픽이 여러 개면 토픽마다
+  producer 를 만들고, 연결이 더 필요하면 producer 를 더 만듭니다(예: 발행 스레드마다 하나).
+- 레코드 토픽이 producer 토픽과 다르면 `send()` 가 `MIMQE_INVALID_ARGUMENT` 로 거부합니다.
+- 옛 `create_producer(config)` / `ILTopicProducer(host, port, name, config)` 모양으로 부르면 `TypeError` 가 납니다.
+- 배치는 **파티션마다** 모입니다. `batchSize`(기본 **262144**, 자바와 같음)는 파티션 배치 하나의 상한입니다. 보낼 때는
+  준비된 파티션 배치들을 봉투 하나에 `maxRequestSize` 까지 싣고, 봉투를 `maxInFlight`(기본 5) 개까지 겹쳐 보냅니다.
+  완결은 I/O 스레드가 하므로 `lingerMs=0` 이어도 `send()` 가 돌아온 시점에 끝나 있다는 보장은 없습니다 - 동기 발행은
+  `send(rec).get()` 입니다. `send(rec, callback)` 으로 콜백(`callback(metadata, exc)`)을 걸 수 있습니다.
+- 멱등 발행은 파티션 배치 단위로 번호를 매깁니다. 멱등이면 `maxInFlight` 는 5 이하여야 합니다.
+- 버퍼(`bufferMemory`)가 차면 `send()` 가 `maxBlockMs` 만큼 기다렸다가 `MIMQE_QUEUE_FULL (buffer memory full ...)` 로
+  거부합니다(전에는 그 자리에서 비웠습니다). 부하 문제이므로 다시 시도할 수 있습니다.
+- 크기 상한: 레코드 하나가 혼자 실린 봉투가 `maxRequestSize` 이하, key 와 속성은 각각 99,999바이트까지입니다. 넘으면
+  `send()` 가 `MIMQE_MSG_SIZE_OVER (...)` 로 거부합니다. 배치는 토픽 세그먼트 크기에도 맞춰 끊습니다. 봉투 건수 상한(10만 건)은
+  없어졌습니다.
+- 멱등 발행에서 리더가 바뀌는 순간, 팔로워가 거절한 배치 뒤의 배치가 먼저 적재되면 앞 배치는 번호가 틈으로 남습니다. 이 배치는
+  `MIMQE_OUT_OF_ORDER_SEQUENCE (sequence gap ...)` 로 **실패**합니다(적재되지 않았습니다). 전에는 이 경우 성공으로 보고되고
+  레코드가 사라질 수 있었습니다.
+- 소비자 배치 읽기가 엔진 저장 v4 응답(2042)을 받습니다. 엔진은 배치를 쪼개지 않아 요청한 개수보다 많이 줄 수 있습니다.
+  `read_batch(max, t)` 는 그래도 **max 이하**를 돌려주고, 넘친 레코드는 구독이 들고 있다가 다음 `read` / `read_batch` 가
+  먼저 줍니다. `COMMIT_AUTO` / `COMMIT_MANUAL` 은 앱에 건넨 레코드까지만 커밋하므로 들고 있던 레코드는 끊기면 다시 옵니다.
+  `COMMIT_IMMEDIATE` 는 엔진이 읽는 순간 배치 끝까지 커밋하므로 들고 있던 레코드도 이미 커밋된 상태라, 앱에 건네기 전에
+  끊기면 다시 오지 않습니다(at-most-once). `seek` 는 들고 있던 레코드를 버립니다. 옛 배치 응답(2024)은 받지 않습니다 -
+  배치 읽기에는 저장 v4 엔진이 필요합니다.
+- **없어진 API**: `ILTopicFrameMsg` 의 발행 조립(`createPublish`, `buildBatchPublishEnvelope`, `patchPidSeq`,
+  `setAckMode`, `setPartition`, `setPidSeq`, `PUBLISH_*_OFFSET`)과 옛 응답 파싱(`getCorrId`, `getResultCode`, `getReason`,
+  `getResultPartition` / `Offset` / `Timestamp` / `Reason`), 상수 `ILC.MIMQ_PUBLISH_MESSAGE` / `MIMQ_PUBLISH_ACK_MESSAGE` /
+  `MIMQ_BATCH_PUBLISH_MESSAGE` / `MIMQ_BATCH_PUBLISH_ACK_MESSAGE`. `ILTopicFrameMsg` 는 구독 전달 수신 전용이 됐습니다.
+- 추가: `ILTopicProducer.get_topic()` / `get_partition_count()`, `ILC.MIMQ_TOPIC_PUBLISH_V2_MESSAGE`(2040) /
+  `MIMQ_TOPIC_PUBLISH_V2_ACK_MESSAGE`(2041), 결과 코드 `ILC.MIMQ_TOPIC_PUBLISH_DUPLICATE`(4164) ~ `FOLLOWER_NODE`(4172),
+  `ILC.MIMQ_TOPIC_BATCH_V4_MESSAGE`(2042)와 수신 전용 `ILTopicBatchV4Msg`.
+
 ## 0.6.11 변경 - 메시지 크기 상한(기본 128MiB), 재시도 보호, 클러스터 편의 개선
 
 - **메시지(프레임) 크기 상한의 기본값이 128MiB 입니다**(엔진 `Runtime@MaxFrameLength` 기본과 같습니다). 넘는 메시지는 **보내기 전에** `MIMQE_MSG_SIZE_OVER` 로 막고 연결은 그대로 둡니다.
@@ -130,12 +167,12 @@ sub.stop_listening()
 
 ### 발행
 
-발행은 producer 단일 경로입니다. 동기 발행은 `send().get()`을 씁니다.
+발행은 producer 단일 경로입니다. producer 하나는 토픽 하나에 묶입니다(0.7.0). 동기 발행은 `send().get()`을 씁니다.
 
 ```python
 from ilink.producer import ILProducerConfig, ILProducerRecord
 
-prod = qmgr.create_producer(ILProducerConfig())
+prod = qmgr.create_producer("ORDER.EVENT", ILProducerConfig())
 meta = prod.send(ILProducerRecord("ORDER.EVENT", "k1", b"payload",
                                   properties={"trace-id": "abc"})).get()
 print(meta.get_partition(), meta.get_offset())
@@ -404,13 +441,13 @@ from ilink.producer import ILProducerConfig
 
 cfg = (ILProducerConfig()
        .acks(1).lingerMs(5).batchSize(32768)
-       .maxRequestSize(1048576)      # 레코드 1건 상한 - 넘으면 send()가 거부
-       .bufferMemory(33554432)       # 미전송 누적 상한
+       .maxRequestSize(1048576)      # 봉투 하나의 상한(레코드 1건도) - 넘는 레코드는 send()가 거부
+       .bufferMemory(33554432)       # 미전송 누적 상한 - 차면 maxBlockMs 까지 기다린다
        .retries(3).retryBackoffMs(100)
        .deliveryTimeoutMs(120000)    # 재시도를 포함한 완결 시한
-       .enableIdempotence(True))     # PID/시퀀스 중복 제거 (acks=1 필요)
+       .enableIdempotence(True))     # PID/시퀀스 중복 제거 (acks=1, maxInFlight 5 이하 필요)
 
-prod = qmgr.create_producer(cfg)
+prod = qmgr.create_producer("ORDER.EVENT", cfg)   # 0.7.0: producer 하나 = 토픽 하나
 print(prod.get_producer_id(), prod.is_connected())
 ```
 

{jetstream_api-0.6.11 → jetstream_api-0.7.0}/README.md

@@ -8,6 +8,43 @@ Python으로 작성된 ILink 클라이언트 API입니다.
 ## 설치 방법
 pip install jetstream-api
 
+## 0.7.0 변경 - 발행 v2: producer 하나 = 토픽 하나, 파티션별 배치, 봉투 겹쳐 보내기 (엔진 v2 필요)
+
+발행 경로를 엔진의 새 발행 형식(v2)으로 바꿨습니다. **엔진도 v2 판이어야 합니다** - 옛 엔진에는 발행이 되지 않고
+(`MIMQE_NOT_SUPPORTED`), 옛 클라이언트(0.6.x)는 v2 엔진에 발행할 수 없습니다. 둘을 함께 올리십시오.
+
+- **producer 하나 = 토픽 하나 = 연결 하나.** `qmgr.create_producer("ORDER.EVENT", config)` 로 만듭니다. 생성할 때 토픽의
+  파티션 수를 받아 두므로 없는 토픽이면 생성 단계에서 `MIMQE_OBJECT_NOT_FOUND` 로 실패합니다. 토픽이 여러 개면 토픽마다
+  producer 를 만들고, 연결이 더 필요하면 producer 를 더 만듭니다(예: 발행 스레드마다 하나).
+- 레코드 토픽이 producer 토픽과 다르면 `send()` 가 `MIMQE_INVALID_ARGUMENT` 로 거부합니다.
+- 옛 `create_producer(config)` / `ILTopicProducer(host, port, name, config)` 모양으로 부르면 `TypeError` 가 납니다.
+- 배치는 **파티션마다** 모입니다. `batchSize`(기본 **262144**, 자바와 같음)는 파티션 배치 하나의 상한입니다. 보낼 때는
+  준비된 파티션 배치들을 봉투 하나에 `maxRequestSize` 까지 싣고, 봉투를 `maxInFlight`(기본 5) 개까지 겹쳐 보냅니다.
+  완결은 I/O 스레드가 하므로 `lingerMs=0` 이어도 `send()` 가 돌아온 시점에 끝나 있다는 보장은 없습니다 - 동기 발행은
+  `send(rec).get()` 입니다. `send(rec, callback)` 으로 콜백(`callback(metadata, exc)`)을 걸 수 있습니다.
+- 멱등 발행은 파티션 배치 단위로 번호를 매깁니다. 멱등이면 `maxInFlight` 는 5 이하여야 합니다.
+- 버퍼(`bufferMemory`)가 차면 `send()` 가 `maxBlockMs` 만큼 기다렸다가 `MIMQE_QUEUE_FULL (buffer memory full ...)` 로
+  거부합니다(전에는 그 자리에서 비웠습니다). 부하 문제이므로 다시 시도할 수 있습니다.
+- 크기 상한: 레코드 하나가 혼자 실린 봉투가 `maxRequestSize` 이하, key 와 속성은 각각 99,999바이트까지입니다. 넘으면
+  `send()` 가 `MIMQE_MSG_SIZE_OVER (...)` 로 거부합니다. 배치는 토픽 세그먼트 크기에도 맞춰 끊습니다. 봉투 건수 상한(10만 건)은
+  없어졌습니다.
+- 멱등 발행에서 리더가 바뀌는 순간, 팔로워가 거절한 배치 뒤의 배치가 먼저 적재되면 앞 배치는 번호가 틈으로 남습니다. 이 배치는
+  `MIMQE_OUT_OF_ORDER_SEQUENCE (sequence gap ...)` 로 **실패**합니다(적재되지 않았습니다). 전에는 이 경우 성공으로 보고되고
+  레코드가 사라질 수 있었습니다.
+- 소비자 배치 읽기가 엔진 저장 v4 응답(2042)을 받습니다. 엔진은 배치를 쪼개지 않아 요청한 개수보다 많이 줄 수 있습니다.
+  `read_batch(max, t)` 는 그래도 **max 이하**를 돌려주고, 넘친 레코드는 구독이 들고 있다가 다음 `read` / `read_batch` 가
+  먼저 줍니다. `COMMIT_AUTO` / `COMMIT_MANUAL` 은 앱에 건넨 레코드까지만 커밋하므로 들고 있던 레코드는 끊기면 다시 옵니다.
+  `COMMIT_IMMEDIATE` 는 엔진이 읽는 순간 배치 끝까지 커밋하므로 들고 있던 레코드도 이미 커밋된 상태라, 앱에 건네기 전에
+  끊기면 다시 오지 않습니다(at-most-once). `seek` 는 들고 있던 레코드를 버립니다. 옛 배치 응답(2024)은 받지 않습니다 -
+  배치 읽기에는 저장 v4 엔진이 필요합니다.
+- **없어진 API**: `ILTopicFrameMsg` 의 발행 조립(`createPublish`, `buildBatchPublishEnvelope`, `patchPidSeq`,
+  `setAckMode`, `setPartition`, `setPidSeq`, `PUBLISH_*_OFFSET`)과 옛 응답 파싱(`getCorrId`, `getResultCode`, `getReason`,
+  `getResultPartition` / `Offset` / `Timestamp` / `Reason`), 상수 `ILC.MIMQ_PUBLISH_MESSAGE` / `MIMQ_PUBLISH_ACK_MESSAGE` /
+  `MIMQ_BATCH_PUBLISH_MESSAGE` / `MIMQ_BATCH_PUBLISH_ACK_MESSAGE`. `ILTopicFrameMsg` 는 구독 전달 수신 전용이 됐습니다.
+- 추가: `ILTopicProducer.get_topic()` / `get_partition_count()`, `ILC.MIMQ_TOPIC_PUBLISH_V2_MESSAGE`(2040) /
+  `MIMQ_TOPIC_PUBLISH_V2_ACK_MESSAGE`(2041), 결과 코드 `ILC.MIMQ_TOPIC_PUBLISH_DUPLICATE`(4164) ~ `FOLLOWER_NODE`(4172),
+  `ILC.MIMQ_TOPIC_BATCH_V4_MESSAGE`(2042)와 수신 전용 `ILTopicBatchV4Msg`.
+
 ## 0.6.11 변경 - 메시지 크기 상한(기본 128MiB), 재시도 보호, 클러스터 편의 개선
 
 - **메시지(프레임) 크기 상한의 기본값이 128MiB 입니다**(엔진 `Runtime@MaxFrameLength` 기본과 같습니다). 넘는 메시지는 **보내기 전에** `MIMQE_MSG_SIZE_OVER` 로 막고 연결은 그대로 둡니다.
@@ -84,12 +121,12 @@ sub.stop_listening()
 
 ### 발행
 
-발행은 producer 단일 경로입니다. 동기 발행은 `send().get()`을 씁니다.
+발행은 producer 단일 경로입니다. producer 하나는 토픽 하나에 묶입니다(0.7.0). 동기 발행은 `send().get()`을 씁니다.
 
 ```python
 from ilink.producer import ILProducerConfig, ILProducerRecord
 
-prod = qmgr.create_producer(ILProducerConfig())
+prod = qmgr.create_producer("ORDER.EVENT", ILProducerConfig())
 meta = prod.send(ILProducerRecord("ORDER.EVENT", "k1", b"payload",
                                   properties={"trace-id": "abc"})).get()
 print(meta.get_partition(), meta.get_offset())
@@ -358,13 +395,13 @@ from ilink.producer import ILProducerConfig
 
 cfg = (ILProducerConfig()
        .acks(1).lingerMs(5).batchSize(32768)
-       .maxRequestSize(1048576)      # 레코드 1건 상한 - 넘으면 send()가 거부
-       .bufferMemory(33554432)       # 미전송 누적 상한
+       .maxRequestSize(1048576)      # 봉투 하나의 상한(레코드 1건도) - 넘는 레코드는 send()가 거부
+       .bufferMemory(33554432)       # 미전송 누적 상한 - 차면 maxBlockMs 까지 기다린다
        .retries(3).retryBackoffMs(100)
        .deliveryTimeoutMs(120000)    # 재시도를 포함한 완결 시한
-       .enableIdempotence(True))     # PID/시퀀스 중복 제거 (acks=1 필요)
+       .enableIdempotence(True))     # PID/시퀀스 중복 제거 (acks=1, maxInFlight 5 이하 필요)
 
-prod = qmgr.create_producer(cfg)
+prod = qmgr.create_producer("ORDER.EVENT", cfg)   # 0.7.0: producer 하나 = 토픽 하나
 print(prod.get_producer_id(), prod.is_connected())
 ```
 

{jetstream_api-0.6.11 → jetstream_api-0.7.0}/ilink/__init__.py

@@ -1,6 +1,6 @@
 """iLink - Python client API for iLink M.O.M. (Message Oriented Middleware)."""
 
-__version__ = "0.6.11"
+__version__ = "0.7.0"
 
 # --- Admin / Service ---
 from .admin import ILAdminService, ILAdminQmgr, ILLogBrowser, ILQueueBrowser

{jetstream_api-0.6.11 → jetstream_api-0.7.0}/ilink/admintopic.py

@@ -9,9 +9,9 @@
 
 .. warning:: 관리 연결에서는 배치가 없다
 
-    레코드 **한 건에 한 번 왕복**한다. 릴레이가 1요청-1응답 고정이라 배치 read
-    (``TOPIC_BATCH_MESSAGE`` 봉투 + 뒤따르는 프레임 N개)와 배치 발행
-    (``BATCH_PUBLISH`` 봉투)은 엔진이 ``MIMQE_UNSUPPORTED_ON_RELAY`` 로 거부한다.
+    레코드 **한 건에 한 번 왕복**한다. 이 모듈은 배치 read 요청을 보내지 않고, 발행은
+    단건(``TOPIC_PUBLISH_ONE``)뿐이다. 데이터 연결의 발행 봉투(v2, 2040)는 ilsvc 가
+    ``MIMQE_INVALID_MSG_TYPE`` 으로 거절해 큐 관리자에 닿지 않는다.
 
     :meth:`ILAdminTopicSubscription.read_batch` 는 제공하지만 **클라이언트가 단건
     read 를 반복**하는 것이라 왕복 수가 줄지 않는다. 대량 소비가 필요하면 리스너

{jetstream_api-0.6.11 → jetstream_api-0.7.0}/ilink/common.py

@@ -51,13 +51,6 @@ class ILC:
     **파이썬 Enum**         ``option``          :class:`MatchOption`
                             채널 속성          :class:`~ilink.properties.ILChannelType` 등
     ======================= =================== ===================================
-
-    .. warning::
-
-       ``ack_mode`` 는 **같은 이름인데 값 집합이 두 가지**다.
-       :meth:`~ilink.msg.ILTopicFrameMsg.setAckMode` 는 ``"1"``/``"0"``,
-       :meth:`~ilink.msg.ILTopicFrameMsg.buildBatchPublishEnvelope` 는
-       ``"A"``/``"I"``/``"M"`` 를 받는다.
     """
 
     def __init__(self):
@@ -252,15 +245,21 @@ class ILC:
     MIMQ_REPORT_MESSAGE = 2002
     MIMQ_LONG_REPORT_MESSAGE = 2003
     MIMQ_LONG_REQUEST_MESSAGE = 2004
-    # pub/sub 데이터 평면 전용 타입 (Phase 3~7).
-    #   단독 PUBLISH(2020)는 엔진이 더 이상 받지 않는다 - 발행은 BATCH_PUBLISH(2025) 봉투로만 간다
-    #   (bare 2020 = 프로토콜 위반으로 연결 종료).
-    MIMQ_PUBLISH_MESSAGE = 2020
-    MIMQ_PUBLISH_ACK_MESSAGE = 2021
+    # pub/sub 데이터 평면 전용 타입.
+    #   0.7.0: 옛 발행 프레임 2020(PUBLISH) / 2021(PUBLISH_ACK) / 2025(BATCH_PUBLISH) / 2026(BATCH_PUBLISH_ACK)은
+    #   엔진과 같은 판에서 걷어냈다 - 발행은 아래 2040 / 2041 뿐이다.
     MIMQ_TOPIC_MESSAGE = 2022
+    #: 0.7.0: 저장 v4 엔진은 보내지 않는다(배치 read 응답은 2042). 구독은 받지 않고 ILTopicFrameMsg 의 해석만 남긴다
     MIMQ_TOPIC_BATCH_MESSAGE = 2024
-    MIMQ_BATCH_PUBLISH_MESSAGE = 2025
-    MIMQ_BATCH_PUBLISH_ACK_MESSAGE = 2026
+    #: 저장 v4 배치 read 응답(엔진 DESIGN-storv4 §3) = IL 프레임 하나. 본문(이진 BE) = u16 version=4, u16 partCount,
+    #: partCount x (i32 partition, i64 startOffset), i32 batchCount, v4 배치 x batchCount. 단건 read 는 그대로 2022 다.
+    MIMQ_TOPIC_BATCH_V4_MESSAGE = 2042
+    #: 발행 v2 봉투(엔진 DESIGN-pubv2). IL 헤더 + 이진 big-endian 본문(version, acks, flags, corrId, topicEpoch,
+    #: 토픽, 파티션 배치 N개 - 배치 = 저장 v4 배치, CRC-32).
+    MIMQ_TOPIC_PUBLISH_V2_MESSAGE = 2040
+    #: 발행 v2 ACK. corrId + 봉투 code / 사유 + 배치 수 + 배치마다 {partition, code, baseOffset, timestamp,
+    #: expectedSeq, 사유}. 봉투 헤더를 못 읽으면 봉투 code / 사유만 싣고 배치 수 0 이다.
+    MIMQ_TOPIC_PUBLISH_V2_ACK_MESSAGE = 2041
     MIMQ_LONG_REQUEST_CODE_LENGTH = 6
     MIMQ_LONG_REQUEST_ARG_LENGTH = 70
     MIMQ_LIST_ITEM_COUNT_LENGTH = 5
@@ -465,6 +464,26 @@ class ILC:
     MIMQ_TOPIC_REBALANCED = 4161
     MIMQ_OUT_OF_ORDER_SEQUENCE = 4162
     MIMQ_INVALID_PID = 4163
+    # 0.7.0 발행 v2 ACK(2041)의 봉투 / 배치 결과 code(엔진 DESIGN-pubv2 §8.1). 성공 4158, 기타 실패 4159,
+    # 순서 오류 4162(expectedSeq), PID 무효 4163 은 위 값을 그대로 쓴다. 실패 code 는 모두 "그 배치는 적재되지 않았다".
+    #: 멱등 중복 = 이미 적재됨(성공 계열). 링 밖이면 baseOffset -1
+    MIMQ_TOPIC_PUBLISH_DUPLICATE = 4164
+    #: FLUSH TOPIC 과 겹침. 비멱등은 재시도, 멱등은 실패
+    MIMQ_TOPIC_PUBLISH_FLUSHED = 4165
+    #: 토픽 epoch 가 바뀜 - TOPIC_METADATA 를 다시 받는다
+    MIMQ_TOPIC_PUBLISH_EPOCH_MISMATCH = 4166
+    #: 토픽 없음 또는 지우는 중
+    MIMQ_TOPIC_PUBLISH_NOT_FOUND = 4167
+    #: key / props 한도, 또는 v3 로 불린 배치가 세그먼트 크기 초과
+    MIMQ_TOPIC_PUBLISH_TOO_LARGE = 4168
+    #: 파티션 범위 / 중복, pid 섞임, 형식 오류, 컴팩트 토픽 키 없음
+    MIMQ_TOPIC_PUBLISH_INVALID_ARGUMENT = 4169
+    #: 저장 v4: 엔진이 늘 검사한다(flags bit0 무시)
+    MIMQ_TOPIC_PUBLISH_CRC_MISMATCH = 4170
+    #: 디스크 가드. 연결은 유지된다
+    MIMQ_TOPIC_PUBLISH_SUSPENDED = 4171
+    #: 사유에 leader=h:p
+    MIMQ_TOPIC_PUBLISH_FOLLOWER_NODE = 4172
 
     MIMQ_REMOVE_SESSION = 3309
     MIMQ_SET_CHANNEL_TIMEOUT = 3310

{jetstream_api-0.6.11 → jetstream_api-0.7.0}/ilink/exception.py

@@ -213,7 +213,7 @@ class ILMsgTypeException(Exception):
             type_code (int): 실제로 받은 메시지 종류. **정수 상수**다 -
                 :data:`ILC.MIMQ_DATA_MESSAGE` (2000) /
                 :data:`ILC.MIMQ_REPORT_MESSAGE` (2002) /
-                :data:`ILC.MIMQ_PUBLISH_MESSAGE` (2020) 등 ``MIMQ_*_MESSAGE`` 계열.
+                :data:`ILC.MIMQ_TOPIC_MESSAGE` (2022) 등 ``MIMQ_*_MESSAGE`` 계열.
             msg (str): 오류 메시지.
         """
         super().__init__(msg)