Fix debug log message in MqttTransportHandler:exceptionCaught()

[yantarou]

Pull Request description

Fix debug log message in MqttTransportHandler:exceptionCaught()

Currently logs the following:

2024-01-02 03:04:05,67890 [...] DEBUG o.t.s.t.mqtt.MqttTransportHandler - [<X>][<Y][<Z>] IOException: {}
java.io.IOException: Connection reset by peer
        at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
[...]

Note the {} in the first line.

This patch makes it print the cause message instead of those brackets:

2024-01-02 03:04:05,67890 [...] DEBUG o.t.s.t.mqtt.MqttTransportHandler - [<X>][<Y][<Z>] IOException: Connection reset by peer
java.io.IOException: Connection reset by peer
        at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
[...]

[ashvayka]

Hi, I believe the fix is not entirely correct. Please update it to :

                log.debug("[{}][{}][{}] IOException: ", sessionId,
                        Optional.ofNullable(this.deviceSessionCtx.getDeviceInfo()).map(TransportDeviceInfo::getDeviceId).orElse(null),
                        Optional.ofNullable(this.deviceSessionCtx.getDeviceInfo()).map(TransportDeviceInfo::getDeviceName).orElse(""),
                        cause);

[yantarou]

I updated the PR description to include timestamps for the logs messages in order to make my problem better visible.

The "problem" is that the exception stacktrace is logged without a timestamp prefix.

java.io.IOException: Connection reset by peer
        at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
[...]

What happens though is that users/operators do filter logs by the timestamp prefix (grep "2024-01-02 03:0" ... or similar) and then the stacktrace gets lost.

Thus, this PR adds the exception message (cause.getMessage()) to the 1st log line.

Your suggestion would just remove the brackets {}, which would leave a line like the following:

2024-01-02 03:04:05,67890 [...] DEBUG o.t.s.t.mqtt.MqttTransportHandler - [<X>][<Y][<Z>] IOException:

That wouldn't help in that case, since we wouldn't know what type of IOException happened.

Does anything speak against adding cause.getMessage()?

[yantarou]

@ashvayka

I appreciate your valuable time and understand that this may just look like a very minor issue to you.

But it affects those that run and support ThingsBoard on a daily basis.

Could you have another look at this PR?

Thanks!