Access violations in TROSuperTCPchannel.SetActive

Hello Remobjects team,

I’m experiencing access violations in tROSynapseSuperTCPChannel and TROSuperTCPChannel.

My application does several million data transfers a day, through the internet, VPN’s, satellite connections, and crappy 4G connections which often break down so my application is truly a massive stress test for the Remoting SDK. There are roughly 100 communication threads running concurrently.

My problem: about once a day an access violation happens somewhere which causes every single communication channel in the program to stop responding. With runtime logging I discovered that if this happens, it is always during deactivation or destruction of a channel. My application does this whenever a host becomes unreachable.

Being unsuccessful in finding the cause, I decided to acquire a debugging tool called Eurekalog last week.

After a few hours of running in my application Eurekalog suddenly fired a breakpoint in the method TROBaseSuperChannel.SetActive because it detected an access violation. The parameter passed to the method was “false” and the breakpoint was triggered in line 1267 (“EventThreadPool”).

I am currently on ROSDK 10.0.0.1523 but this stability problem has plagued me for many months now. I am currently in the process of finding out what was the last Remobjects version that would run stable because I’m desperate to get back to a stable situation, even if it requires me to revert to an older Delphi version.

Hi,

try to update TROBaseSuperChannel.SetActive (uROBaseSuperChannel.pas) as

procedure TROBaseSuperChannel.SetActive(const Value: Boolean);
...
    if (fWorkerThread <> nil) then SetInactive;
    fActive := Value;
    if fActive then begin
      EventThreadPool; // <<< moved

have you tried to use TROIndySuperTCPChannel ?
it may work more stable in your situation because TROSynapseSuperTCPChannel and TROSuperTCPChannel use the raw sockets

1 Like

Hi EvgenyK, thanks for the patch, I’ll test it on one of our backup systems and report back!

This fix appears to improve stability indeed!

1 Like