Hi, we are in the process of migrating to RemObjects SDK version 10.0.0.1469 from 9.6.113.1419 for Delphi and .NET (servers and clients in both platforms, SuperTCP with BinMessage and AES encryption envelopes in most cases). .NET services are built using Visual Studio 2017, for Delphi we have at the same time migrated from XE7 to 10.3.3. After the upgrade we have experienced lots of problems with the RemObjects communication, e.g. EROTimeOut exceptions. It is not 100% errors in the remote procedure calls, but many. We have updated the RemObjects auto-generated files (interface, invoker) in the involved projects. Any idea what has caused these problems and how we can fix them? Are there any breaking changes in version 10 that require code changes?
In general no, there should be no issues during upgrade.
Could you provide more details?
Do these issues occur on .NET <-> Delphi or Delphi <-> Delphi or .NET <-> .NET communications?
Is it possible to create a testcase?
If you do not want to expose such details here then you can send them to support@
Hi and thanks for a quick reply. So far we have not been able to test all system aspects due to these issues. But the problems we have seen so far have been Delphi clients to either .NET or Delphi servers.
Could you create a simple testcase? Make a copy of one of your server apps and remove all business logic from it. Literally leave there just a single service method without any implementation.
Then create a simple client that would call that method using your usual approach. Will the issue persist?
While you will need to spend some time on this such testcase would help to pinpoint the issue and as a result will save much more of your time than you would spend on it.
Regards
Hi,
can you specify what exactly SuperTCP components you are used?
we have renamed some Synapse and Indy channels.
see Breaking Changes article for more details.
It can be your case - nowadays TROSuperTcpChannel/TROSuperTcpServer is a RO socket based channels. in 9.x, it was Indy-based channels
Hi again. For the clients, we use TROSuperTcpChannel, and for the Delphi server we use TROSuperTcpServer. I can test if using a TROIndySuperTCPChannel makes a difference.
Yes, that did seem to make the trick, thanks! I will search for usage of TROSuperTcpChannel/TROSuperTcpServer in our Delphi applications, change them to the Indy versions and make some more checks.
Hi,
looks like Indy based components work more stable in your case
Well actually, we had some cases where applications reported only about 1 out of 400 calls as successful, so using stable/unstable are probably not the right words here… (when we go from 0,25% success rate to 100%). But I will update you here once I have rolled out new versions of our applications and made some more tests.