EROTimeout and EIdHTTPProtocolException exceptions

Remoting SDK
1

Hi,

I seem to be getting these two exceptions generated by my server application and semi-regular intervals. I’m trapping and recording exceptions to the event log and my application seems to be generating these two exceptions every hour or few hours although the exact intervals vary.

I have no idea what these represent or where the issue is. I have noticed that, on a couple of occasions, my server has become completely unresponsive to clients and I have to restart it but I don’t know if it’s related.

The EROTimeout exception seems to be generated in the uROBaseSCHelpers.TROBaseSuperChannelWorker.WaitForAck function whereas the TIdHTTPProtocolException exception happens in IdHTTP.TIdHTTPProtocol.ProcessResponse.

Can you shed any light on what these exceptions mean and why they might be generated.

2

from this post ,

EIdHTTPProtocolException is raised when a protocol error happened.
Basically, that is at any time the client is unable to get the final
resource from the server. It can be a 404 (page not found), 5XX (Server-
side error), 403 (Access denied), 302 (redirect) if handleredirect is set
to false or any similar.

can you receive more details like errorcode, message from this exception?

If you switch to synapse based channels, this problem with EROTimeout will be reproduced?

3

I’m recording the stack trace at the time of the exception which is as follows:

An exception occurred: [EIdHTTPProtocolException] HTTP/1.1 302 Found

(0000E4A4){ClarityServer.exe} [0040F4A4] System.@IntfClear (Line 35702, “System.pas” + 10) + $0
(00539EC4){ClarityServer.exe} [0093AEC4] IdGlobal.BytesToString (Line 7204, “IdGlobal.pas” + 22) + $1E
(000098FD){ClarityServer.exe} [0040A8FD] System.@RaiseExcept (Line 19696, “System.pas” + 51) + $0
(00AD07F9){ClarityServer.exe} [00ED17F9] IdHTTP.CheckException (Line 2608, “IdHTTP.pas” + 18) + $4A
(00AD0A23){ClarityServer.exe} [00ED1A23] IdHTTP.TIdHTTPProtocol.ProcessResponse (Line 2686, “IdHTTP.pas” + 42) + $1
(00AD1138){ClarityServer.exe} [00ED2138] IdHTTP.TIdCustomHTTP.DoRequest (Line 2920, “IdHTTP.pas” + 34) + $E
(00005AC5){ClarityServer.exe} [00406AC5] System.@ReallocMem (Line 4473, “System.pas” + 21) + $0
(00ACC912){ClarityServer.exe} [00ECD912] IdHTTP.TIdCustomHTTP.Post (Line 805, “IdHTTP.pas” + 19) + $18
(00AE8180){ClarityServer.exe} [00EE9180] WebUtils.THTTPPostThread.Execute (Line 129, “WebUtils.pas” + 7) + $16
(00005AC5){ClarityServer.exe} [00406AC5] System.@ReallocMem (Line 4473, “System.pas” + 21) + $0
(000D54F5){ClarityServer.exe} [004D64F5] System.Classes.ThreadProc (Line 14601, “System.Classes.pas” + 21) + $5
(00005AC5){ClarityServer.exe} [00406AC5] System.@ReallocMem (Line 4473, “System.pas” + 21) + $0
(0000A0C4){ClarityServer.exe} [0040B0C4] System.ThreadWrapper (Line 23704, “System.pas” + 45) + $0
(00005AC5){ClarityServer.exe} [00406AC5] System.@ReallocMem (Line 4473, “System.pas” + 21) + $0

With regards to Synapse, I’ve never tried using these channels as I don’t know much about it or how it compares to the Indy ones - can I just switch out the channels with no other code changes? Are there any things I need to be aware of? Not sure what the pros/cons of Synapse vs Indy are to be honest.

4

Incidentally, I’m also experiencing an issue where my server channels stop listening for no apparent reason and I have to restart the server to get them working again. This is happening quite regularly with the HTTP channel but also with the TCP channel, albeit rarely. No exceptions appear to be generated, the server just stops listening on those channels, as revealed by NETSTAT -a

This could be totally unrelated but I thought I’d mention it anyway.

5

You can just replace Indy based channels with synapse ones. no ones changes are required.

This article contains list of HTTP client/server channels that are present in ROSDK.

Also you can replace Indy channels with TROWinInetHTTPChannel/TROWinHttpServer. They are wrappers for WinInet HTTP implementation provided by the Windows.

6

Ok thanks - I’ve just tried replacing the Indy channels with the Synapse ones for TCP comms and it all seems to work still.

Are the Synapse channels recommended over Indy then? Not sure what the advantages are - is it faster and/or more robust than the Indy ones?

7

Synapse and Indy are just different implementations of the same things.
in some scenarios, Indy works better, in other - Synapse.
So test them and detect more appropriate for your case
but I can recommend to use the same library for client and server.

8

Ok. I was just wondering if there was any kind of list of the pros and cons of Indy vs Synapse so I could see the differences.

Also, how “compatible” are the libraries. Is there anything I need to be aware of or should it all just work. Bit worried that switching from the Indy channels to Synapse is going to invalidate a load of our testing and we’ll need to check everything again to make sure no problems are introduced, or are they completely interchangeable?

9

They are completely interchangeable

10

Ok thanks, I think I’ll switch over to the Synapse and WinInet HTTP channels and see if this alleviates the problems I’ve been getting.

11

Well after some time and testing this seems to have cured the Indy exception but the aforementioned EROTimeout exception is still happening sporadically.

Can you shed any light on what this exception means and whether I should be concerned. Is it something that can happen during “normal” operations or is it indicative of something wrong? The stack trace for the exception is entirely within the RO framework code so I can’t work out what has actually caused it.

12

This exception is raised when server’s confirmation isn’t received in specified Timeout by client.
You can try to increase AckWaitTimeout value (default is 10sec) or disable this at all via SkipAck.

13

It’s actually being raised by the server, which suggests it might be the other way around and the server isn’t receiving a confirmation from the client?

I can try those solutions but I’m more concerned by whether I should be worried about this exception. Is it normal for such a confirmation to not be received now and then or does it indicate something is wrong?
Just wondering whether I can safely ignore it or whether I should spend a load of time trying to track down the root cause.

14

If exception is raised on server-side, this means that server package isn’t received by client so it is possible that package is lost.
package can be “system ping”, event or result of method execution.