Aias00 opened a new issue, #7470: URL: https://github.com/apache/shenyu/issues/7470
## Finding `MqttPluginDataHandler.handlerPlugin()` starts the MQTT server for every enabled plugin data event: - `shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-mqtt/src/main/java/org/apache/shenyu/plugin/mqtt/handler/MqttPluginDataHandler.java:39-44` - `shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/MqttBootstrapServer.java:57-68` - `shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/MqttBootstrapServer.java:75-84` The handler does not check whether the server is already running or whether the effective MQTT config changed. `MqttBootstrapServer.start()` allocates fresh `NioEventLoopGroup` instances before binding `ENV.getPort()`. If an enabled UPDATE arrives while the previous listener is still bound, the second start can fail at bind time after allocating new event loops. Those new groups are not shut down on the failure path. The disable path also decides whether to call `shutdown()` by probing `127.0.0.1:<configured port>` instead of using server lifecycle state, which makes lifecycle decisions depend on a port probe rather than the object that owns the channel. ## Trigger / caller flow `CommonPluginDataSubscriber.onSubscribe(pluginData)` receives an UPDATE for the `mqtt` plugin with `enabled=true`, then calls: `MqttPluginDataHandler.handlerPlugin(pluginData)` -> `MqttBootstrapServer.init()` -> `MqttBootstrapServer.start()`. Calling the handler twice with the same enabled config is enough to reach the duplicate start path. ## Actual behavior The gateway starts a second MQTT bootstrap for an already-running listener. The bind can fail because the port is still in use, and the event-loop groups allocated for that second attempt are not closed. ## Expected behavior Enabled updates should be idempotent. The plugin should no-op identical enabled updates and restart only after a material config change, shutting down the previous server before creating the new bootstrap. `start()` should also clean up allocated event loops when bind fails. ## Impact A normal runtime config refresh can break the MQTT listener lifecycle and leak Netty resources, eventually leaving MQTT traffic unavailable or degraded until process restart or manual cleanup. ## Suggested fix Track running state and the effective MQTT config in `MqttPluginDataHandler` or `MqttBootstrapServer`. Compare incoming config before starting: 1. If enabled and config is unchanged, return. 2. If enabled and config changed, shut down the old server, then start with the new config. 3. If start fails after allocating event loops, close those groups in the failure path. 4. Replace the disable-time port probe with state owned by the bootstrap server. ## Existing issue de-dupe This is not #7458, which is about retained MQTT binary payload corruption. This issue is about duplicate server startup and lifecycle/resource cleanup on enabled config updates. ## Validation - Source flow inspected at `a89b6a2338c24e978428b731e8f1edce86022418`. - `./mvnw -pl shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-mqtt -Dtest=MqttPluginDataHandlerTest test -Dcheckstyle.skip -Drat.skip=true -Djacoco.skip=true` passed. Existing tests do not cover duplicate enabled UPDATE. ## Reviewed Revision And Validation Apache ShenYu 2.7.2-SNAPSHOT, master at a89b6a2338c24e978428b731e8f1edce86022418. Severity: medium. Confidence: high. Isolated review traced identical enabled updates through the real data subscriber and bootstrap init/start path. No live broker was started. Current source references: - `shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-mqtt/src/main/java/org/apache/shenyu/plugin/mqtt/handler/MqttPluginDataHandler.java:39` - `shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/MqttBootstrapServer.java:57` - `shenyu-protocol/shenyu-protocol-mqtt/src/main/java/org/apache/shenyu/protocol/mqtt/MqttBootstrapServer.java:75` No implementation fix or full deployed end-to-end validation was performed by this review. Source-flow and runtime evidence are distinguished above. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
