Open
Description
[Feature Request] 咨询:开源发行版中数据订阅(SUBSCRIPTION_ENABLED)的启用时间安排
[Feature Request] Question: The schedule for enabling the data subscription (SUBSCRIPTION_ENABLED) in the open-source distribution
背景描述 & 咨询诉求
您好!我在开源版 IoTDB 2.0.x(测试环境为 2.0.11,单机部署)上准备搭建
「IoTDB → Flink 1.20」的实时消费链路,尝试订阅 API 时遇到了报错:
Msg: org.apache.iotdb.jdbc.IoTDBSQLException: 1912: Subscription is not enabled.
排查后确认了原因:iotdb-core/node-commons/.../conf/CommonConfig.java 中的总开关是关闭的,
public static final boolean SUBSCRIPTION_ENABLED = false;在 2.0.x(含 2.0.11)乃至当前 master 分支上默认为 false,且不读取 properties
配置,因此无法通过配置项打开,只能随版本变更。
已做过的功课
- 阅读了官方 UserGuide 的 Data Subscription 章节(其中介绍订阅为 V1.3.3 起支持的功能);
- 对比 v1.3.4:该版本无此常量,订阅可用;
- 查看了近期 master 上订阅相关 PR(如 [Bugfix] Disable Subscription and Pipes containing data insertion under Ratis #19053、[Subscription] Add a switch for consensus fallback polling #19062、Support progress retention for initial and snapshot subscription topics #19019 等),确认订阅模块
仍在活跃维护和加固; - 我所在的环境确认 必须停留在开源 2.x(Table 模型等新能力是刚需),因此
无法回退 1.3.x 作为替代方案。
本次咨询的具体问题
- 订阅功能目前停留在
SUBSCRIPTION_ENABLED = false,预计在哪个版本(或 大致时间线)
会在开源发行版中默认启用?是 2.0.x 的后续 patch、2.x 的 minor 版本,还是
3.x 大版本? - 若时间线尚未确定,能否透露阻塞点的大致方向?例如——是仍在修复共识订阅
在 Ratis 集群下的问题(类似 [Bugfix] Disable Subscription and Pipes containing data insertion under Ratis #19053 的场景)、table-model 订阅收尾、还是其他? - 社区是否接受:在开关保持关闭的前提下,为开发/测试环境提供一个可选的
配置项(如iotdb-common.properties中的enable_subscription)让用户自行
承担风险试用?如可接受,愿提交 PR 讨论。
环境信息
- Version: iotdb 2.0.11(开源发行版,单机)
- 客户端: iotdb-session 2.0.11 / flink-streaming-java 1.20.5 / JDK 17
- 部署形态: 单机 1C1D 启动
谢谢!如需我补充任何复现脚本或日志,随时告知。
Reacted by Johnny-ZTSD
Metadata
Metadata
Assignees
Labels
No labels
Activity
Caideyipi commentedon Nov 3, 2026
目前 Apache IoTDB 的订阅功能仍有较多问题需要进一步验证。虽然仓库中已有 initial 和 snapshot 模式的测试,但是测试覆盖并不充分;最近 PR 主要支持的incremental模式也有类似问题。此外,现有测试对共识订阅、历史数据读取、故障恢复以及多订阅并发下的资源表现,仍需要进一步补齐和持续验证。
启用 SUBSCRIPTION_ENABLED 不仅会开放订阅接口,也会启动相关运行时任务并引入订阅数据的内存开销。考虑到目前仍存在功能和测试覆盖上的不确定性,在开源发行版中默认开启除了订阅数据的一致性问题之外,还可能影响正常数据同步,增加 region 写入/查询负担,阻塞正常的 configNode 控制指令执行,导致 WAL 磁盘占用泄漏最终阻写,多任务、高并发下导致内存 OOM等,带来额外运维负担。我们倾向于在相关场景验证充分、风险可控后,再讨论默认启用的时间安排。
Johnny-ZTSD commentedon Nov 3, 2026
@Caideyipi 了解这个情况了,非常感谢支持、解惑。还是比较期待这个特性的正式上线~