Stuck with communication lost

[treebyte_srl]

Hello,

I refer to THIS topic.

because I'm in stuck with strange behaviours.

I have a usual architecture service on server / vcl application of client. One server, about 80 clients.
Client OS are different, from Windows XP to Windows 7 to Windows 8. Not yet Windows 10.
Client PCs stay turned on for entire weeks.

Client application include a datamodule and a form, and stay in tray area.
On datamodule there are two RtcHttpClient, one for send data from client to server, and one to request data from server to client.
It could seems strange, I decide to use this configuration because timing of send data and request data are different, and to avoid "collision" between send and request. Timing are ruled by two timers.
Plus, I have another application that uses a third RtcHttpClient on the same server address, but requests from this application are few during the day.

Clients have a proxy set through a registry settings on HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL.
I don't know any further details about it.

Actually, settings of RtcHttpClient are:

UseProxy=True
UseWinHTTP=False
UseSSL=False
ReconnectOn=ConnectLost
UserLogin completely empty

The point is: if the service on server is online, all works well without problems.
If the service goes offline for a variety of reasons (phisical server restart, database is unavailable etc...), some clients hangs and stop communicate. Not all clients, not the same clients on different days.

"Hang" means that timers events on client application are no longer execute, even if GUI seem active, since I'm able to click in the tray area and exit from it.

I'm unable to figure out where is the trouble, so I appreciate any suggestion.

Thanks in advice and best regards

Giuseppe Garzotto

[D.Tkalcec (RTC)]

Without more information about the way you are using the components (and how they are set up), I guess (based on the info you have provided) that your Clients have stopped re-connecting to the Server, because you have the ReconnectOn.ConnectError and/or ConnectFail properties on one or more of your TRtcHttpClient components set to FALSE. If only ReconnectOn.ConnectLost is set to TRUE, your Clients will STOP trying to re-connect to your Server after a failed connection attempt, which will happen if you restart the Server or if the Server becames unavailable long enough for a Client to lose the connection and try to make at least one new connection attempt when the Server is still unavailable.

If you want all your Clients to keep trying to open a new connection to your Server in case a connection gets lost, without you having to manually call Connect in code, I recommend setting the AutoConnect property and ALL ReconnectOn properties (ConnectError, ConnectFail and ConnectLost) to TRUE. Doing this eliminates the need to manually call Connect, while at the same time making sure that a new connection will be open when required, as soon as the Server becomes available. I guess, you are already using events to keep the communication going by setting the AutoRepost property high enough, or implementing events like OnResponseAbort, OnResponseError and OnRepostCheck.

If that does not solve your problem, then I will need more details about the way you are using RTC components.

Best Regards,
Danijel Tkalcec

[treebyte_srl]

Hello Danijel,

thanks for the reply and sorry for lack of informations. The problem is strange, so it wasn't so clear for me what to ask and what informations provide.

TrtcHttpClient components have AutoConnect set to TRUE, and only ReconnectOn.ConnectLost set to TRUE.

AutoPost of TrtcClientModule is set to 3, and I manage the folllowing events:

- TrtcHttpClient.ConnectLost and ConnectFail to simply track the event to a log file
- TrtcResult.OnRequestAborted to perform a SkipRequests and DisconnectNow(True) operations. I thought this was the best way to manage errors, probably I was wrong.

So, I surely follow your advice on setting also ConnectError and ConnectFail to TRUE (both ?) and try to deploy my application with this settings.
But this open another question: at every timer event, I call a TrtcHttpClient.Connect(False, False), I perform the operations I need and, at the end, I call a TrtcHttpClient.DisconnectNow.

Following your words, if AutoConnect is set to TRUE the explicit Connect call is potentially useless. I'm right ?
And the DisconnectNow call at the end, is useless too ? Or worse, harmful ? Or is instead necessary ?

I'm doing this to track on log file exactly when the connection is open and when is closed, but now I'm very doubtful about this approach.

Thanks in advice, best regards

Giuseppe Garzotto

[D.Tkalcec (RTC)]

When using AutoConnect=True, you should NOT make manual calls to Connect (even though, doing this is not harmful) and you should ABSOLUTELY AVOID using the Disconnect or DisconnectNow methods (this is harmful), because a manual call to Disconnect or DisconnectNow will disable the AutoConnect feature and you will have to call Connect manually aftewards, to enable AutoConnect again.

The only time you might want to use DisconnectNow is during Client Application shutdown, but this is only to avoid possible Access Violations in case your Client is running in Multi-Threaded mode and you are doing some things from RTC events in background threads. But even then, calling DisconnectNow might NOT be necessary with the latest RTC SDK version, since all RTC events will now be automatically disabled in component destructors. In other words, it is good practice to use DisconnectNow before destroying any objects and/or components used from your code implemented on RTC components, but it is not absolutely necessary with the latest RTC SDK version.

Best Regards,
Danijel Tkalcec

[treebyte_srl]

It's all clear. I have installed v7.17 2015Q4, so Disconnect / DisconnectNow methods are not necessary.

Many thanks for your help.

Giuseppe Garzotto