Upgrade from RTC v436 to v514

[xstarter]

Hello Danijel,

I moved some days ago to latest version RTC what available for my subscription and found one changing that I made myself. Can you add this changing to main code base, please?

Unit rtcSocketHttpSrvProv.pas:

procedure TRtcSocketHttpServerProvider.TriggerDataSent;

Was:
    if not Response.Done then
      Response.Done := LenToSend=0;
Now:
    if not Response.Done then
      Response.Done := LenToSend<=0;

Sometimes I have LenToSend<0 when using JavaScript AJAX requests to my server with RTC.

Thank you.

[D.Tkalcec (RTC)]

If you are getting into a situation where "Response.Done" should be set to TRUE when "LenToSend" is below zero, chances are high that you are doing something wrong. For example, if you are using the "WriteHeader" method, you have to set the correct "Response.ContentLength" value. If you leave the "Response.ContentLength" value undefined and call "WriteHeader", it will be assumed that you want to stream raw content out. Since there is no information about the content length, the "Response.Done" property won't be modified and the response should be terminated with a "Disconnect" call.

RealThinClient SDK v5.16 (and later) was extended with overflow control for "LenToSend" and "DataOut" values. To activate it, simply declare the "RTC_DEBUG" compiler directive. This will write LOG entries in case a DataOut value should ever be greater than the LenToSend counter. Such conditions are NOT normal and would be a clear indicator that something is wrong. Either with the way the components are being used, or with the underlying sockets API.

This topic has already been discussed - here.

Best Regards,
Danijel Tkalcec

[xstarter]

Thanks a lot for your answer. Really, my way was not correct. Now I tried to set
Srvr.Response.Done := True;
before WriteHeader and it works fine as I can see.

By the way, did you found any memory leaks in v514? My tests with FastMM4 says:

Code:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):
13 - 20 bytes: TRtcEvent x 1, UnicodeString x 57, Unknown x 79
85 - 100 bytes: TRtcWorkerThread x 1

A memory block has been leaked. The size is: 20
This block was allocated by thread 0x1790, and the stack trace (return addresses) at the time was:
40495A 
406083 
40665E 
799EB2 [rtcSyncObjs.pas][rtcSyncObjs][rtcSyncObjs.TRtcEvent.Create][61]
778D54C4 [ZwClearEvent]
75B6687D [ResetEvent]
7E61B7 [rtcThrPool.pas][rtcThrPool][rtcThrPool.TRtcWorkerThread.Create][926]
7E4EE7 [rtcThrPool.pas][rtcThrPool][rtcThrPool.GetThread][543]
7E5D06 [rtcThrPool.pas][rtcThrPool][rtcThrPool.TRtcThread.PostJob][836]
9552A3 [rtcSocketCliProv.pas][rtcSocketCliProv][rtcSocketCliProv.TRtcSocketClientThread.Create][949]
954807 [rtcSocketCliProv.pas][rtcSocketCliProv][rtcSocketCliProv.TRtcSocketClientProvider.Connect][728]
The block is currently used for an object of class: TRtcEvent

A memory block has been leaked. The size is: 52
This block was allocated by thread 0x668, and the stack trace (return addresses) at the time was:
40495A 
407BF3 
408080 
4090AF 
7E6346 [rtcThrPool.pas][rtcThrPool][rtcThrPool.TRtcWorkerThread.Execute][957]
778D65E4 [ZwSetEvent]
75B66804 [SetEvent]
4301D1 [SysUtils][SysUtils][SysUtils.TMultiReadExclusiveWriteSynchronizer.UnblockReaders]
4C4A61 [ExceptionLog.pas][ExceptionLog][ExceptionLog.HookedThreadExecute][16008]
45ADC5 [Classes][Classes][Classes.ThreadProc]
407B3A 
The block is currently used for an object of class: UnicodeString

After returning to v436 no any leaks. I am sorry, I have not access now to PRO support as my subscription ends, so I can try only v514.

[xstarter]

Forgot to say. While program exit with v514 used I have exception "Range check error", with v436 no such messages, so I think this message from RTC. My EurekaLog don't show there this error correctly, so I can not be sure.

[D.Tkalcec (RTC)]

1. Range check errors and Memory Leaks are most likely caused by multi-threaded connections left open when the Application is terminating and destroying objects used by those connections. In order to get a clean Application shutdown, you have to close all connections before any objects used by connection components are destroyed. If you don't do this, there is a chance that some code in the background will try to access objects which have already been destroyed, which can result in range check errors, access violations and memory leaks.

2. You should NOT be setting "Response.Done" to TRUE in your own code. Instead, before calling "WriteHeader", you should set the correct value for "Response.ContentLength". This has to be the exact number of bytes you will be sending out by using the "Write" or "WriteEx" method. If you use "WriteHeader", but don't set a value for "Response.ContentLength" first, the component will assume that you want to send a raw stream out, but don't know the content length. In that case, content body has to be terminated with a disconnect.

PS. If you are sending the complete content out from a single event (for example, from OnCheckRequest or OnDataReceived), you don't have to use the WriteHeader method. Instead, you can use the Write and/or WriteEx methods and let the component calculate the content length for you. The content body will be prepared in memory and the complete content, along with the correct header, will be sent immediately after your event completes.

Best Regards,
Danijel Tkalcec