Long running RO calls do not return (since v10.0.0.1489)

Remoting SDK
,
1

We have a .NET RO server and a delphi RO client.
We just migrated the client to v10.0.01489

The RO calls have a custom timeout of 120 seconds (TROSuperTCPChannel.RequestTimeout)
However for calls that last long (it appears longer than 25 seconds) we do not get a response.

The client keeps waiting and after 120 seconds we get the timeout exception

Below the callstack when the exception hits (in a worker thread)
afbeelding

FYI: For testing purposes I was debugging the .NET server and I see the RO server exit the RO server function and execute the _Message.FinalizeMessage function well in time.

Is something broken in the latest release?
My latest test were with RO server version 10.0.0.1489 (but this upgrade did not solve anything) it looks like a delphi client issue.

Can this be investigated ASAP

2

Hi,

can you specify from what version of RO you have migrated?
in .1449 we have renamed some channels: see breaking changes for details.

so as temporary workaround, you can back to indy-based channels

3

We come from v10.0.0.1463 if I am not mistaken.

We still use TROSuperTcpChannel which our sources show to be derived from class(TROBaseSuperTCPChannel)

This is on my development machine with v1489
Does this mean we have 3 supertcp classes to choose from?

4

Hi,

actually you have 4 supertcp client channels in delphi: https://docs.remotingsdk.com/Servers/Concepts/SuperTCPChannel/

5

Hi,

I can’t reproduce this issue with simple testcase.
Can you create a simple testcase, pls?
you can attach it here or drop email to support@ for keeping privacy

6

i’m confused, in the breaking changes you state:
Channels were renamed:

  • Indy prefix was added to Indy Super TCP channels:
    • TROSuperTCPServer -> TRO Indy SuperTCPServer
    • TROSuperTCPChannel -> TRO Indy SuperTCPChannel

but in the 4 channels link TROSuperTCPServer is still listed?
as is the TROSuperTCPChannel

so how do we need to interpret this?

7

Hi,

some time ago we have added our socket version of channels and named it w/o prefix:

  • TROHTTPServer
  • TROSuperHTTPServer
  • TROSuperTcpServer & TROSuperTcpChannel
  • TROTcpServer

also we have normalized name of existing channels, so all Indy-based channels have Indy prefix and all Synapse-based channels have Synapse prefix.

8

Did you test with TROSuperTCPChannel?
Can you tell me what implementation TROSuperTCPChannel is based on?
I have followed your suggestion and it looks like switching to TROIndySuperTCPChannel solves the problem. I still need to confirm this in our product installed with our customer.

9

Hi,

yes

our socket-based version

Edit: seems, you need to add a fix from this topic