TTMSQTTClient Access Violation with Version V 2_0_4_1 in Connection

DEV TMS MQTT
1

TTMSMQTTNetworkConnection in TMS.MQTT.Connection:
If FIsReady is true there is not always checking if FidTcpClient still exists.
FIsReady will only be set to false when StocketOnStatus is called by IOHandler with status hsDisconnected.
If IOHandler does not send the status and DestroyIndyComponents was called, then you get access violation in Close function.
IOHandler might be destroyed to early?

after many times per second
ERROR - TTMSMQTTNetworkConnection -- Exception reading data from the socket.
Connection has been closed.

you get
ERROR - TTMSMQTTNetworkConnection -- Exception while disconnecting...
Zugriffsverletzung bei Adresse 006D88F7 in Modul 'MQTTGateway.exe'. Lesen von Adresse 00000000

2

Thank you for reporting this issue!

The next MQTT component version will check if FIdTcpClient is assigned in TTMSMQTTNetworkConnection.Close.

3

Actually the problem starts with multiple errors per second trying to read or write via SSL connection:
10.07.23 09:18:04: Exception reading data from the socket.
10.07.23 09:18:04: => EIdConnClosedGracefully - Die Verbindung wurde erfolgreich geschlossen.
10.07.23 09:18:04: Exception reading data from the socket.
10.07.23 09:18:04: => EIdConnClosedGracefully - Die Verbindung wurde erfolgreich geschlossen.
...
After client connection is lost the TTMSMQTTCommThread still tries to read from connection!
Writing to the socket is also not prevented and leads to similar errors.
(KeepAlive Thread doesn't help either)

4

We would need to know all the TTMSMQTTClient property values in order to reproduce this issue in our computers. Please, provide all the property values.
We would also need to know the what operating system you use and the Delphi version.

5 
BrokerPort = 8883
UseSSL = True
KeepAliveSettings.KeepAliveInterval = 10
KeepAliveSettings.AutoReconnect = True
KeepAliveSettings.AutoReconnectInterval = 5
TimeOutSettings.Read = 1000
OnConnectedStatusChanged = TMSMQTTClient1ConnectedStatusChanged
OnPacketReceived = TMSMQTTClient1PacketReceived
OnPacketSent = TMSMQTTClient1PacketSent
OnRawPacketReceived = TMSMQTTClient1RawPacketReceived
OnRawPacketSent = TMSMQTTClient1RawPacketSent
OnServerRedirection = TMSMQTTClient1ServerRedirection
OnAuthReceived = TMSMQTTClient1AuthReceived
OnOutgoingPacketTooBig = TMSMQTTClient1OutgoingPacketTooBig
OnSSLIOHandlerConfiguration = TMSMQTTClient1SSLIOHandlerConfiguration
OnPingRequest = TMSMQTTClient1PingRequest
OnPingResponse = TMSMQTTClient1PingResponse
OnPingTimeout = TMSMQTTClient1PingTimeout
OnPublishReceived = TMSMQTTClient1PublishReceived
OnSubscriptionAcknowledged = TMSMQTTClient1SubscriptionAcknowledged
OnUnSubscribeAcknowledged = TMSMQTTClient1UnSubscribeAcknowledged
Logger = TMSMQTTFileLogger1
Version = '2.0.4.1'

Privat customer Broker is on amazonaws.com.
Client runs can take an hour or two before an error occurs.
The most events are used for logging.
TMSMQTTClient1SSLIOHandlerConfiguration is used to set ASSLIOHandler.SSLOptions:
Method:=sslvTLSv1_2;
Mode := sslmClient;
RootCertFile := BrokerRootCert;
CertFile := BrokerCertFile;
KeyFile := BrokerKeyFile;

6

I edited my previous message too late. What OS and Delphi version do you use ?
Have you tried the latest TMS MQTT component version ?

7

Application runs on Windows Server 2019.
Delphi IDE is Embarcadero® Delphi 10.4 Version 27.0.40680.4203 Enterprise (Sydney)

8

Do you know what MQTT broker software is running in the amazonaws server ?

9

I will ask the customer.

10

Maybe check of connection status in TTMSMQTTNetworkConnection.Read or TTMSMQTTNetworkConnection.Write is missing.

I think that "Connection Closed Gracefully" can occur in some cases without firing all events as if the connection was closed normally.

11

Customer uses AWS IoT core as MQTT broker.

12

Please, update to the MQTT component version 2.0.5.2 when it's available at tmssoftware.com and try it.

That version triggers the missing OnStatus events.

You can also use the TMSMQTTClient1PingTimeout and TMSMQTTClient1ConnectedStatusChanged procedures to reconnect. If you detect a ping timeout you could reconnect in TMSMQTTClient1ConnectedStatusChanged if then "AConnected" parameter is false.

Check that the AWS IoT Core broker limits are not exceeded :

The TMS MQTT component implements the official MQTT specification but AWS IoT Core broker has some differences :

13

Thanks for the update and the detailed description.

I allready tried version 2.0.5.1 which fails again last night due to exception EIdConnClosedGracefully not handled in connection read from socket or write to socket (causing multiple errors per second).
Trying MQTTClient.Disconnect does not help. it only pauses the KeepAliveThread and connection status remains csConnected!

I will try version 2.0.5.2 and will check for AWS broker issues.

14

Version is not yet available!

15

2.0.5.2 is released

16

Thx!

Now testing with 2.0.5.2

17

Reconnect is working somehow, but
it can take up to a few minutes before the Indy client socket is reestablished
while CommThread is still trying to send data.

14.07.23 05:03:03: Exception reading data from the socket.
14.07.23 05:03:03: => EIdConnClosedGracefully - Die Verbindung wurde erfolgreich geschlossen.
14.07.23 05:03:03: TMSMQTTClient1ConnectedStatusChanged: ConnectionLost
14.07.23 05:03:07: TMSMQTTClient1ConnectedStatusChanged: Reconnecting
14.07.23 05:03:19: Reconnect-Timer ausgeführt...(our reconnect timer!)
14.07.23 05:03:19: IsConnected = 0
14.07.23 05:03:19: ConnectionStatus = csReconnecting
14.07.23 05:03:19: LogLevel is now #5 ------------------------------
14.07.23 05:03:19: Keep Alive thread - Resumed
14.07.23 05:03:19: TMSMQTTClient1ConnectedStatusChanged: Connecting
14.07.23 05:03:19: CLIENT- Connecting ---------------------------
14.07.23 05:03:19: Comm thread - Resumed
14.07.23 05:03:19: TMSMQTTClient1RawPacketSent
14.07.23 05:03:19: CLIENT- Handeling Outgoing Packet ---------------------------
14.07.23 05:03:19: CLIENT- Sending packet to WriterThread ---------------------------
14.07.23 05:03:19: CLIENT- Packet added to queue ---------------------------
14.07.23 05:03:20: Comm thread - Packet: 11296 Qos:1 - SENDING - attempt: 0 ---
14.07.23 05:03:20: Comm thread - Packet: 11297 Qos:1 - SENDING - attempt: 0 ---
14.07.23 05:03:20: Comm thread - Packet: 11298 Qos:1 - SENDING - attempt: 0 ---
...
14.07.23 05:03:22: Keep Alive thread - No Connection. Requesting Reconnect.
came every 5 seconds between Comm thread packet sending attempt, while status remain csReconnecting
...
14.07.23 05:03:42: Comm thread - Packet: 12364 Qos:1 - SENDING - attempt: 0
14.07.23 05:03:42: Comm thread - Packet: 12365 Qos:1 - SENDING - attempt: 0
14.07.23 05:03:42: Connecting Indy TCP Client
14.07.23 05:03:42: Socket allocated ...
14.07.23 05:03:42: TIdSSLIOHandlerSocketOpenSSL - resolving...
14.07.23 05:03:42: TIdSSLIOHandlerSocketOpenSSL - connecting...
14.07.23 05:03:42: TIdTCPClient - connected...
14.07.23 05:03:42: Comm thread - Packet Qos:0 - SENDING ---
14.07.23 05:03:42: TMSMQTTClient1PacketSent
14.07.23 05:03:42: TMSMQTTClient1RawPacketReceived
14.07.23 05:03:42: TMSMQTTClient1ConnectedStatusChanged: Connected

18

Is the application publishing lots of messages each second? It seems that the Comm Thread is trying to send all pending messages before reconnecting.

The next MQTT component version will have more information in the debug log and debugging these issues should be easier.

If all the pending messages can be discarded while reconnecting then call TTMSMQTTClient.Session.Clear; in the TTMSMQTTClient.OnBeforeReconnect event.

19

The next MQTT component version 2.0.5.4 will have higher priority for the CONNECT and DISCONNECT packets.
Please, update to that version when it's available at tmssoftware.com.
You won't need to call TTMSMQTTClient.Session.Clear when you upgrade to that version and the reconnection times will be much shorter.

20

Thanks for the update.
A new version with your changes is currently running, we will observe the behavior.