MQTT: Configure quiesceTimeout in disconnectForcibly()

[artembilan]

Discussed in #10093

^{Originally posted by leonard2901 June 10, 2025}
Hello,
I use spring-integration-mqtt (phao3) to communicate with a Mosquitto instance. For integration testing, I start Mosquitto using Testcontainers.

This generally works fine, but the tests encounter a 30-second timeout when the client attempts to disconnect, as the container has already been stopped. I have looked through the code, especially the doStop() method in MqttPahoMessageDrivenChannelAdapter. There this.client.disconnectForcibly(getDisconnectCompletionTimeout()); is called. In this overload the default QUIESCE_TIMEOUT of 30 seconds is used.

In my tests I would like to just disconnect immediately and discard any potentially pending messages.

Is there a way to configure the quiesceTimeout or any other way to disconnect without a timeout?

Any help is appreciated! :)

[artembilan]

I suggest we indeed introduce such a quiesceTimeout option on the AbstractMqttMessageDrivenChannelAdapter and use it, respectively, in that doStop() implementations.

[cppwfs]

Couldn't we use the existing disconnectCompletionTimeout that exists in the AbstractMqttMessageDrivenChannelAdapter?

In the example below setting the disconnectCompletionTimeout drops the runtime of this test from around 40 seconds to about 5 seconds.

main...cppwfs:spring-integration:mqtt-paho-disconnectCompletionTimeout

[artembilan]

The target API is like this:

	/**
	 * Disconnects from the server forcibly to reset all the states. Could be useful when disconnect attempt failed.
	 * <p>
	 * Because the client is able to establish the TCP/IP connection to a none MQTT server and it will certainly fail to
	 * send the disconnect packet.
	 * 
	 * @param quiesceTimeout the amount of time in milliseconds to allow for existing work to finish before
	 * disconnecting. A value of zero or less means the client will not quiesce.
	 * @param disconnectTimeout the amount of time in milliseconds to allow send disconnect packet to server.
	 * @throws MqttException if any unexpected error
	 * @since 0.4.1
	 */
    void disconnectForcibly(long quiesceTimeout, long disconnectTimeout) throws MqttException;

since it comes with two args, that is not a surprise end-user is asking for a second one unsupported right now anyhow.

I think we should incorporate your findings about the test timing into a fix for this issue.

Thanks

[cppwfs]

I see. Thanks for the explanation!