Hi all, PR #18708 proposes replacing Reactor Netty with the JDK HttpServer/HttpsServer for IoTDB’s Prometheus /metrics endpoint: https://github.com/apache/iotdb/pull/18708
Reactor Netty is useful for reactive, non-blocking network applications. Our Prometheus reporter serves just one HTTP route that returns a metrics snapshot, so the Reactor stack seems heavier than necessary. The PR reports that the all-in-one distribution shrinks from about 105 MB to 99 MB, with the JAR count dropping from 97 to 77. Using the JDK server is also an established approach for a standalone metrics endpoint. The Prometheus Java client’s standalone HTTP exporter uses the JDK HttpServer, and the Micrometer documentation uses it in an example scrape endpoint: https://prometheus.github.io/client_java/exporters/httpserver/ https://docs.micrometer.io/micrometer/reference/implementations/prometheus.html The change still has costs. IoTDB would be responsible for worker limits, overload behavior, TLS/mTLS, and error handling. We also need to account for dependencies previously supplied transitively: the current PR’s MQTT integration tests fail because netty-buffer is missing from the DataNode runtime classpath. This appears fixable, but must be addressed before merging. I’d appreciate the community’s thoughts: 1. Does the simpler endpoint and smaller distribution justify replacing Reactor Netty here? 2. Should IoTDB use the JDK server directly, or use an established standalone exporter such as the Prometheus Java client’s HTTP exporter? 3. What compatibility or operational behavior should we explicitly test before making the change? I lean toward replacing Reactor Netty for this endpoint, provided we fix the MQTT packaging issue and verify authentication, TLS/mTLS, restart behavior, and concurrent scrapes. I’d welcome other views. Thanks, Haonan
