Destroying tROSynapseSuperTCPChannel takes a very long time

Remoting SDK
1

Hello Remobjects team,

I’m having the situation that sometimes the destructor of tROSynapseSuperTCPChannel takes as long as one minute to finish. Is there anything I can do to speed that up?

Kind regards,
Arthur

2

Hello

Please try to explicitly close the channel by setting its Active property to false before destroying it.

4

Hi AntonK,

that’s exactly what I’m doing. I set “active” to false in the channel before calling the destructor. I have numerous channels in separate threads. So when the program is terminating, all these threads will try to close their connections quasi-simultaneously.

I have the impression that it’s especially the connections that have unreachable hosts that need a long time to terminate. Maybe because they’re still busy trying to connect.

5

Hi,

try to use our new TROSuperTcpChannel that uses native WinSock2/POSIX sockets (v10 branch). it may show better results because doesn’t use 3rd party libraries

6

There’s something strange here, when I try the new tROSuperTCPChannel (Version 10.0.0.1471) then I’m unable to communicate with a Remobjects server that uses a tROSynapseSuperTCPServer.

The other varieties (tROSynapseSuperTCPChannel and tROIndySuperTCPChannel) both connect and communicate successfully with that server.

7

Hi,

I can’t reproduce this issue with the MegaDemo sample:

Untitled
Untitled890×931 67.1 KB

Can you retest this sample on your side, pls?

8

Using Windows 10 X64, Delphi Rio 10.3.3, Remobjects 10.0.0.1471, compiling in 32-bit mode:

A freshly compiled MegaDemoClient.dproj will not start, it throws runtime error 217 @008336AC.

When I use tROSuperTCPChannel in my own application, it throws eROTimeout and eROSuperChannelException (no connection available) when I try to call a method. With both Indy and Synapse TCP superchannels it works fine.

This is the structure of the data module with the connection:

object BinaryChannelModule: TBinaryChannelModule
  OldCreateOrder = False
  Height = 262
  Width = 257
  object Message: TROBinMessage
    Envelopes = <
      item
        Envelope = AES_Encryption_envelope
      end>
    MinSizeForCompression = 1024
    Left = 52
    Top = 72
  end
  object ClientChannel: TROSuperTcpChannel
    OnFailure = ClientChannelException
    OnException = ClientChannelException
    StoreActive = False
    DispatchOptions = []
    OnLoginNeeded = SessionInvalid
    OnReceiveStream = ChannelReceiveStream
    OnSendStream = ChannelSendStream
    ServerLocators = <>
    SynchronizedProbing = False
    TargetUrl = 'supertcp://localhost:8095'
    Host = 'localhost'
    AckWaitTimeout = 15000
    AutoReconnect = True
    OnDisconnected = ClientChannelDisconnected
    OnConnected = ClientChannelConnected
    Left = 48
    Top = 16
  end
  object AES_Encryption_envelope: TROAESEncryptionEnvelope
    EnvelopeMarker = 'AES'
    Password = 'Some super secret password'
    Left = 56
    Top = 136
  end
end
9

Hi,

try to open main form in IDE and rebuild app.
in rare cases it can cause some errors.

can you create a simple testcase that reproduces failure with TROSuperTCPChannel channel, pls?
you cen send it directly to support@ for keeping privacy or attach it here

10

Strange, in a simple testcase I can’t reproduce it, the communication between tROSynapseSuperTCPServer and TROSuperTCPChannel works there. In my own application, it does not work with TROSuperTCPChannel but it works fine with the other two super TCP channels.

This application also contains a built-in Intraweb webpage that acts as a user interface, maybe there’s some side effect between the two frameworks that I don’t know about.

But regarding my original problem (when my program shuts down, it ends several hundred threads gracefully. Shutting all these threads down simultaneously takes minutes. Each has a connected tROSynapseSuperTCPChannel and it is the destruction of these channels that takes so long),

I have just discovered that I could mitigate it a lot by serializing the channel destruction with a critical section. That reduced the time my program needs to shutdown dramatically (now it takes 30 seconds instead of 3 minutes).

11

I can review your testcase (if it wasn’t complicated) for discovering why TROSuperTCPChannel doesn’t work here. you can send it to support@ for keeping privacy.